-
以下哪些场景中适合使用 QueryCache?
电商业务,库存表
游戏业务,积分表
ERP 系统,配置表
博客系统,点赞数表
QueryCache 只适用于静态的、更新量很少的表,只有 C 满足条件。
-
以下哪个操作可以提升 MySQL 主实例的查询性能?
A
将 innodb_buffer_pool_size 从 10G 改成 12G
B
将 sort_buffer_size 从 1M 改成 4M
C
将 innodb_flush_log_at_trx_commit 从 1 改成 2
D
将 rpl_semi_sync_master_enabled 从 1 改成 0
CD 影响的是更新性能,不会影响查询性能。
-
以下哪些场景会导致事务回滚?
A
事务执行部分语句后,客户端先执行 rollback 再执行 commit
B
事务执行部分语句后,客户端先执行 commit 再执行 rollback
事务执行部分语句后,客户端与服务端断开连接
事务执行部分语句后,最新执行的语句碰到死锁,并被服务端终止执行
B 项已经提交,后面的 rollback 无效; D 项中只是当前语句被中断,并不会回滚整个事务。
-
表 t1 使用 InnoDB 引擎, 以下哪个场景会导致语句 Q1: select * from t1 limit 1 被堵住?
另一个线程在 Q1 执行之前,执行了 alter table t1 add index(f1) ,当前处于“拷贝数据到临时表”阶段
另一个线程在 Q1 执行之前,执行了 truncate table t1, 当前处于 waiting for metadata lock 阶段
另一个线程在 Q1 执行之前,执行了 delete from t1, 且未执行完成
另一个线程在 Q1 执行之前,执行了 lock table t1 write,并执行完成
A 加上索引支持 Online DDL,不会阻塞查询; C 是 DML 语句,也不会阻塞查询。
-
关于自增主键,以下说法错误的是?
自增主键字段在达到定义类型上限后,再插入一行记录,则会报“主键冲突”错误
一个只有 insert 场景,且所有 insert 语句都不指定自增主键值的表,自增主键列的值一定是连续且递增的
将自增主键定义从 int 修改成 bigint 的时候,会导致全表重做
在一个空表里,先指定自增主键值是 10,插入一行记录;然后,以不指定自增值的方式插入 10 行数据,会报“主键冲突”错误
A 会报错,因为自增 ID 不会修改,报主键冲突错误。 B 回滚或者批量插入可能会产生 ID 空洞。 C 主键字段修改,会全表重做。 D 第一插入 10 之后,下一个自然生成的 ID 是 11,因此后续不会冲突。
-
RR 隔离级别下,表 t 的建表结构和初始化数据如下:
1 create table t(id int primary key,c int) engine=innodb; 2 insert into t values(1,1),(11,11),(21,21); 在会话 1 执行如下语句:
1 begin; 2 select * from t lock in share mode; 那么,会话 2 的以下哪些语句会被进入“等待行锁”的状态?
insert into t values(15,15);
update t set c=c+1 where id=15;
delete from t where id=15;
alter table t add d int;
BC 都不会被堵住, D 是进入等待 MDL 状态,不是等待行锁。
-
以下关于唯一索引说法正确的是?
联合索引不能创建为唯一索引
当插入一行新数据时,唯一索引上不能使用 change buffer 优化
唯一索引查询比普通索引略快,是因为可以少扫描一行
当使用 replace into 时,如果碰到唯一索引冲突,会删除冲突的数据,然后再插入新的一行
A 是可以的。 B 因为要判断数据是否冲突,需要将数据页读入内存,因此无法使用 change buffer 优化。
-
以下关于覆盖索引说法正确的是?
执行 select count(*) from t 时,如果有其他索引,则会优先使用其他索引,并使用覆盖索引
如果一个查询可以使用覆盖索引,就不需要排序
当无法使用覆盖索引,需要回表的时候,每次回表都会让 rows_examined 统计值加 1
覆盖索引必须使用联合索引的全部字段,如果只使用部分字段,则无法触发覆盖索引优化
B 覆盖索引和排序无关; C 回表不会导致 rows_examined 增加; D 只需要使用部分字段也是可以的 。
-
在 innodb_flush_log_at_trx_commit=1 的配置下,以下说法错误的是?
一个事务提交的时候,与它相关的 redo log 一定已经写入到磁盘
一个事务还没有提交的时候,与它相关的 redo log 一定没有写入到磁盘
一个事务回滚的时候,与它相关的 redo log 一定已经写入到磁盘
一个事务回滚的时候,与它相关的 redo log 一定没有写入到磁盘
一个事务的 redo log 可能会被别的事务代刷入磁盘,因此 BCD 均无法保证。
-
表 t 使用半年后数据量达到了 1G,以下哪些操作会减少 t.ibd 文件占用的空间?
使用 delete * from t where … 命令删掉一半数据
使用 delete * from t 命令删掉全部数据
使用 truncate table t 命令删掉全部数据
使用 alter table t engine=innodb 命令重做数据
AB 都只是做标记删除,空间不会回收。
-
以下关于排序的说法,正确的是?
如果一个查询返回结果包含主键字段,而且查询中没有指定 order by,则查询结果会按照主键排序返回
假设主键字段是 ID, 则 select * from t order by id desc 不需要使用内部排序
语句 select … order by rand() 一定会使用内部排序
排序过程需要的临时内存,不会占用 innodb buffer pool 的内存
A 会按照使用索引的顺序返回。
-
以下关于使用索引,说法正确的是?
查询条件是 where k=N,并且 N 和 k 的数据类型不一致时,一定无法使用索引
查询条件是 where k+1=N 时,一定无法使用索引
当能够使用索引时,extra 字段会显示 using index
语句指定 force index 使用一个索引的时候,优化器就不会去判断其他索引的执行代价了
A 类型符合转换规则还是可以使用; C using index 是覆盖索引。
-
以下关于主备架构的说法,正确的是?
将一主两从架构升级到一主 10 从,可能会影响查询效率
主库异常重启后,由于会生成新的 binlog,会导致从库因为找不到对应位置,与主库无法重新建立主备关系
网络闪断导致主备连接断开,网络恢复后,主备关系可以在不需要人工干预的情况下自动恢复
当主库试图用 purge binary logs to 命令删除 binlog 文件,而这个文件还没有被备库消费的时候,主库上的 purge 命令会失败
B 主库的 binlog 生成是按照 ID 递增的,重启不影响这个规律,能够自动接上; D purge 命令可以执行,只是会导致从库因拿不到 binlog 而主备断开。
-
以下关于并行复制的说法,正确的是?
在并行复制场景下,备库执行完命令后,机制上必须保证备库的 binlog 日志里事务的顺序,与主库的 binlog 里事务顺序一致
MySQL 5.6 按库并行复制场景下,同一个库上两个表的更新命令,机制上必须保证备库的 binlog 日志里事务的顺序,与主库的 binlog 里事务顺序一致
MySQL 8.0 Writeset 并行复制场景下,同一行上的两个更新,机制上必须保证备库的 binlog 日志里事务的顺序,与主库的 binlog 里事务顺序一致
MySQL 8.0 Writeset 并行复制场景下,表 t 在主库上是 InnoDB 表,在从库上被改成 MyISAM 表,字段和索引信息一样,此时表 t 上的更新,无法使用并行复制
A 不需要做这个保证,否则并行复制的效果很差; D 中并行判断是在 server 层做的,与引擎无关。
-
以下关于主备延迟的说法,正确的是?
seconds_behind_master > 0 时,表示一定有延迟
seconds_behind_master = 0 时,表示一定没有延迟
主库执行一个持续 10 分钟的 delete 语句后,会在备库上观察到明显延迟
主库执行一个持续 1 秒的 drop table t 命令后, 在备库上最多看到 1 秒,或最多略高于 1 秒的延迟
B 可能是主库信息没有回传,也可能是小于 1 秒的延迟; D 备库上如果有在表 t 上执行的长事务,可能会导致 drop 命令无法应用,引起长时间延迟。
-
以下关于备份恢复,说法正确的是?
逻辑全量备份为了确保拿到 InnoDB 的一致性视图,需要在备份开始的时候启动一个事务,并持续到备份结束
如果实例 A 和实例 B 中都有表 db1.t1,使用 InnoDB 引擎,要把实例 A 的这个表数据覆盖到实例 B,可以直接拷贝数据文件 t1.ibd 覆盖,再重启实例 B,即可
如果实例 A 和实例 B 中都有表 db1.t1,使用 MyISAM 引擎,要把实例 A 的这个表数据覆盖到实例 B,可以直接拷贝数据文件 t1.MYD 和 t1.MYI 覆盖,再重启实例 B,即可
用备份来恢复数据时,只要 binlog 保存够久,最近的备份文件如果出错,则可以用前一个备份来恢复,只是需要应用的 binlog 更多
B 不能,因为 InnoDB 的信息有一部分保存在系统表,直接拷贝文件,表空间 id 和索引 id 对不上。
-
以下关于内存表说法,正确的是:
在主备架构中,主库在重启之后,会由于内存表中数据丢失,导致主备同步停止
在主备架构中,备库在重启之后,会由于内存表中数据丢失,导致主备同步停止
物理备份无法备份内存表数据
逻辑备份无法备份内存表数据
A 主库重启后,binlog 里面会追加一句删除 memory 数据的语句,因此备库也会清空数据,主备不会不一致;而 B 中备库重启后,会导致主备不一致。 D 逻辑备份是用 select 方法,可以备份内存表数据
-
以下关于 kill 的说法,正确的是?
用 Kill 命令停止一个线程执行,会让事务直接回滚
当一个事务本身处于回滚过程中,对它执行 kill 命令,会终止回滚过程
当一个线程处于 Killed 状态时,对它再执行一个 kill 操作,这个操作本身没有效果
在 MySQL 标准客户端执行 ctrl+c 来终止会话,是通过给当前会话发一个 kill 命令来实现的
A 不会回滚事务,只是终止当前语句; B 回滚过程一定会完成。
-
以下关于语句执行,说法正确的是?
join 语句一定会使用临时表
join 语句可以使用驱动表的索引,但被驱动表一定会全表扫描
语句其他部分都相同的情况下,对比 union 和 union all 两种写法, union all 的性能更好
group by 执行时,会默认按照 group by 的字段排序
A 项中,如果可以用上索引,也不会使用临时表; B 项中,被驱动表的索引也可以被使用; C 项中,union all 不需要做去重,性能更高。
-
以下关于权限,说法正确的是?
修改一个用户的权限,去掉它的 super 权限位,这个用户当前已经存在的连接的权限不会受影响
将实例设置为 read_only 后, super 权限依然可以执行更新操作
执行 flush tables with read lock 之后,super 权限依然可以执行更新操作
普通账户占用一个行锁后,super 账户需要使用这个行锁时,会触发普通账户执行回滚操作
C 执行 FTWRL 后,所有账号不能执行更新操作;D 行锁上没有这种优先级设定。