MySQL高级面试题整理

Posted 2023-04-02 废废丿

1. 执行流程

1. mysql客户端先与服务器建立连接
2. Sql语句通过解析器形成解析树
3. 再通过预处理器形成新解析树，检查解析树是否合法
4. 通过查询优化器将其转换成执行计划，优化器找到最适合的执行计划
5. 执行器执行sql

2. MYISAM和InNoDB的区别

1. MYISAM：不支持外键、不支持事务、表锁
2. InNoDB：支持外键、支持事务、行锁

3. 什么是索引

1. 索引是数据结构
2. 索引的目的是提高查询效率

4. 索引的优劣势

1. 优势：提高数据检索的效率、降低数据排序和分组的成本
2. 劣势：降低更新表的速度、占用空间

5. 聚簇索引与非聚簇索引

1. 聚簇索引：叶子结点存储的是行数据
2. 非聚簇索引：叶子结点存储的是物理地址值，访问数据总是需要二次查找(回表)

6. MySQL索引分类

1. 按功能逻辑分：主键索引、唯一索引、全文索引、普通索引
2. 按物理实现方式分：聚簇索引、非聚簇索引
3. 按作用字段分：单列索引、联合索引

1. 主键索引：设定为主键后数据库会自动建立索引
2. 单值索引：一个索引只包含单个列
3. 唯一索引：索引列的值唯一，可以为空
4. 复合索引：一个索引包含多个列

7. 不同的存储引擎支持的索引类型

1. InNoDB：支持B-tree、Full-text，不支持Hash索引
2. MyISAM：支持B-tree、Full-text，不支持Hash索引
3. Archive：不支持B-tree、Full-text，Hash索引
4. NDB：支持Hash索引，不支持B-tree、Full-text
5. Memory：支持B-tree、Hash索引，不支持Full-text索引

8. 创建索引

1. 隐式创建：有主键约束、唯一性约束、外键约束的字段会自动创建索引
2. 显示创建：create Table table_name Index index_name

9. 查看索引

1. 方式一：show create table 表名;
2. 方式二：show index from 表名;

10. 适合创建索引的11种情况

1. 字段的数值有唯一性的限制
2. 频繁作为where查询条件的字段
3. 经常使用group by和order by 的列
4. update、delete的where条件列
5. distinct字段需要创建索引
6. 多表联查时，创建索引的注意事项：第一，连接表的数量尽量不要超过三张；第二，对where条件创建索引；第三，对连接的字段创建索引
7. 使用列的类型小的创建索引
8. 使用字符串前缀创建索引
9. 使用区分度高的创建索引
10. 联合索引中使用最频繁的列放到联合索引的左侧
11. 在多个字段都需要创建索引的情况下，联合索引优于单值索引

11. 限制索引的数目：单表的索引尽量不要超过6个

1. 索引需要占用磁盘空间，需要维护
2. 索引会影响insert,update,delete等语句的性能‘
3. 优化器在选择执行计划时，如果有多个索引可以用，会增加优化器生成执行计划，降低查询效率

12. 不适合创建索引的情况

1. 在where中使用不到的字段不建议建立索引
2. 数据量小的表不建议建立索引
3. 字段有大量重复的数据(重复率达到百分之10)不建议建立索引
4. 经常更新的表不建议建立索引
5. 无序的字段不建议建立索引(例如身份证)
6. 不经常使用的索引建议删除
7. 不要定义冗余或者重复的索引

13. explain的四种格式

1. 传统格式：输出是表格形式
2. JSON格式：输出信息最详细的格式，包含了执行的成本信息
3. TREE格式：描述各个部分之间的关系和各个部分的执行顺序
4. 可视化输出：

14. explain各字段含义

1. select_type：区别普通查询、联合查询、子查询
2. table：查询的表名
3. type：all--->index--->range--->ref--->eq_ref--->const
4. key：当前查询实际使用的索引
5. key_len：索引中使用到的字节数，可以算出具体使用了索引中的哪些列
6. ref：显示索引的那一列被使用
7. rows：执行查询时必须检查的行数
8. extra：不适合在其他列中显示但十分重要的额外信息

15. extra：

1. Using filesort：使用了非索引字段排序
2. Using temporary：临时表、根据非索引字段进行分组
3. Using index：使用索引字段进行了查询
4. Using where：使用where进行了过滤
5. Using join buffer：使用了缓存，非主键缓存
6. impossible where：where子句的值总是false

16. 索引失效的10种情况

1. 在使用联合索引不满足最左匹配原则
2. 使用了select *
3. 索引列上有计算
4. 索引列上用了函数
5. 字段类型不同
6. like查询条件中左边包含%
7. 列对比
8. 使用or关键字：or关键字连接的字段都要建立了索引则不会失效，否则索引失效
9. not in,not exists使用在非主键字段会导致索引失效
10. order by后没有where和limit条件，满足最左匹配原则但是多个字段的排序规则不同

17. 索引优化

1. 物理查询优化：通过索引和表连接方式优化
2. 逻辑查询优化：通过SQL等价变换提升查询效率

18. 范式的种类

1. 第一范式(1NF)：数据表中每个字段必须满足原子性
2. 第二范式(2NF)：满足第一范式、必须有主键、非主键字段必须完全依赖主键；
3. 第三范式(3NF)：满足第二范式、非主键字段只和主键字段直接关联(即非主键字段不能依赖于其他非主键字段)
4. 巴斯-科德范式(BCNF)：满足第三范式、并且只有一个候选键
5. 第四范式(4NF)：
6. 第五范式(5NF,又称完美范式)：

19. 如何定位调优问题

1. 用户的反馈
2. 日志分析
3. 服务器资源使用监控
4. 数据库内部状态监控

20. 优化MySQL的参数

1. innodb_buffer_pool_size：innoDB类型的表和索引的最大缓存
2. Key_buffer_size：索引缓冲区的大小
3. table_cache：同时打开表的个数
4. quert_cache_size：查询缓冲区的大小

21. 事务的原子性、一致性和持久性由事务的redo和undo日志保证

1. redo日志：重做日志，提供再写入操作
2. undo日志：回滚日志，回滚到某个记录版本

MySQL最全整理！高级java开发工程师面试题

数据库

1. MySQL 索引使用有哪些注意事项呢？

可以从三个维度回答这个问题：索引哪些情况会失效，索引不适合哪些场景，索引规则

索引哪些情况会失效

• 查询条件包含or，可能导致索引失效
• 如何字段类型是字符串，where时一定用引号括起来，否则索引失效
• like通配符可能导致索引失效。
• 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
• 在索引列上使用mysql的内置函数，索引失效。
• 对索引列运算（如，+、-、*、/），索引失效。
• 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
• 索引字段上使用is null， is not null，可能导致索引失效。
• 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
• mysql估计使用全表扫描要比使用索引快,则不使用索引。

索引不适合哪些场景

• 数据量少的不适合加索引
• 更新比较频繁的也不适合加索引
• 区分度低的字段不适合加索引（如性别）

索引的一些潜规则

• 覆盖索引
• 回表
• 索引数据结构（B+树）
• 最左前缀原则
• 索引下推

2. MySQL 遇到过死锁问题吗，你是如何解决的？

我排查死锁的一般步骤是酱紫的：

• 查看死锁日志show engine innodb status;
• 找出死锁Sql
• 分析sql加锁情况
• 模拟死锁案发
• 分析死锁日志
• 分析死锁结果

3. 日常工作中你是怎么优化SQL的？

可以从这几个维度回答这个问题：

• 加索引
• 避免返回不必要的数据
• 适当分批量进行
• 优化sql结构
• 分库分表
• 读写分离

4. 说说分库与分表的设计

分库分表方案，分库分表中间件，分库分表可能遇到的问题

分库分表方案:

• 水平分库：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
• 水平分表：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
• 垂直分库：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
• 垂直分表：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

常用的分库分表中间件：

• sharding-jdbc（当当）
• Mycat
• TDDL（淘宝）
• Oceanus(58同城数据库中间件)
• vitess（谷歌开发的数据库中间件）
• Atlas(Qihoo 360)

分库分表可能遇到的问题

• 事务问题：需要用分布式事务啦
• 跨节点Join的问题：解决这一问题可以分两次查询实现
• 跨节点的count,order by,group by以及聚合函数问题：分别在各个节点上得到结果后在应用程序端进行合并。
• 数据迁移，容量规划，扩容等问题
• ID问题：数据库被切分后，不能再依赖数据库自身的主键生成机制啦，最简单可以考虑UUID
• 跨分片的排序分页问题（后台加大pagesize处理？）

5. InnoDB与MyISAM的区别

• InnoDB支持事务，MyISAM不支持事务
• InnoDB支持外键，MyISAM不支持外键
• InnoDB 支持 MVCC(多版本并发控制)，MyISAM 不支持
• select count(*) from table时，MyISAM更快，因为它有一个变量保存了整个表的总行数，可以直接读取，InnoDB就需要全表扫描。
• Innodb不支持全文索引，而MyISAM支持全文索引（5.7以后的InnoDB也支持全文索引）
• InnoDB支持表、行级锁，而MyISAM支持表级锁。
• InnoDB表必须有主键，而MyISAM可以没有主键
• Innodb表需要更多的内存和存储，而MyISAM可被压缩，存储空间较小，。
• Innodb按主键大小有序插入，MyISAM记录插入顺序是，按记录插入顺序保存。
• InnoDB 存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全，与 MyISAM 比 InnoDB 写的效率差一些，并且会占用更多的磁盘空间以保留数据和索引

6. 数据库索引的原理，为什么要用 B+树，为什么不用二叉树？

可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数，为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？

为什么不是一般二叉树？

如果二叉树特殊化为一个链表，相当于全表扫描。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。

为什么不是平衡二叉树呢？

我们知道，在内存比在磁盘的数据，查询效率快得多。如果树这种数据结构作为索引，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块，但是平衡二叉树可是每个节点只存储一个键值和数据的，如果是B树，可以存储更多的节点数据，树的高度也会降低，因此读取磁盘的次数就降下来啦，查询效率就快啦。

那为什么不是B树而是B+树呢？

1）B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。

2）B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。

7. 聚集索引与非聚集索引的区别

• 一个表中只能拥有一个聚集索引，而非聚集索引一个表可以存在多个。
• 聚集索引，索引中键值的逻辑顺序决定了表中相应行的物理顺序；非聚集索引，索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。
• 索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
• 聚集索引：物理存储按照索引排序；非聚集索引：物理存储不按照索引排序；

何时使用聚集索引或非聚集索引？

8. limit 1000000 加载很慢的话，你是怎么解决的呢？

方案一：如果id是连续的，可以这样，返回上次查询的最大记录(偏移量)，再往下limit

select id，name from employee where id>1000000 limit 10.

方案二：在业务允许的情况下限制页数：

建议跟业务讨论，有没有必要查这么后的分页啦。因为绝大多数用户都不会往后翻太多页。

方案三：order by + 索引（id为索引）

select id，name from employee order by id  limit 1000000，10

方案四：利用延迟关联或者子查询优化超多分页场景。（先快速定位需要获取的id段，然后再关联）

SELECT a.* FROM employee a, (select id from employee where 条件 LIMIT 1000000,10 ) b where a.id=b.id

9. 如何选择合适的分布式主键方案呢？

• 数据库自增长序列或字段。
• UUID。
• Redis生成ID
• Twitter的snowflake算法
• 利用zookeeper生成唯一ID
• MongoDB的ObjectId

10. 事务的隔离级别有哪些？MySQL的默认隔离级别是什么？

• 读未提交（Read Uncommitted）
• 读已提交（Read Committed）
• 可重复读（Repeatable Read）
• 串行化（Serializable）

Mysql默认的事务隔离级别是可重复读(Repeatable Read)

11. 什么是幻读，脏读，不可重复读呢？

• 事务A、B交替执行，事务A被事务B干扰到了，因为事务A读取到事务B未提交的数据,这就是脏读
• 在一个事务范围内，两个相同的查询，读取同一条记录，却返回了不同的数据，这就是不可重复读。
• 事务A查询一个范围的结果集，另一个并发事务B往这个范围中插入/删除了数据，并静悄悄地提交，然后事务A再次查询相同的范围，两次读取得到的结果集不一样了，这就是幻读。

12. 在高并发情况下，如何做到安全的修改同一行数据？

要安全的修改同一行数据，就要保证一个线程在修改时其它线程无法更新这行记录。一般有悲观锁和乐观锁两种方案~

使用悲观锁

悲观锁思想就是，当前线程要进来修改数据时，别的线程都得拒之门外~ 比如，可以使用select…for update ~

select * from User where name=‘jay’ for update

以上这条sql语句会锁定了User表中所有符合检索条件（name=‘jay’）的记录。本次事务提交之前，别的线程都无法修改这些记录。

使用乐观锁

乐观锁思想就是，有线程过来，先放过去修改，如果看到别的线程没修改过，就可以修改成功，如果别的线程修改过，就修改失败或者重试。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

13. 数据库的乐观锁和悲观锁。

悲观锁：

悲观锁她专一且缺乏安全感了，她的心只属于当前事务，每时每刻都担心着它心爱的数据可能被别的事务修改，所以一个事务拥有（获得）悲观锁后，其他任何事务都不能对数据进行修改啦，只能等待锁被释放才可以执行。

乐观锁：

乐观锁的“乐观情绪”体现在，它认为数据的变动不会太频繁。因此，它允许多个事务同时对数据进行变动。实现方式：乐观锁一般会使用版本号机制或CAS算法实现。

14. SQL优化的一般步骤是什么，怎么看执行计划（explain），如何理解其中各个字段的含义。

• show status 命令了解各种 sql 的执行频率
• 通过慢查询日志定位那些执行效率较低的 sql 语句
• explain 分析低效 sql 的执行计划（这点非常重要，日常开发中用它分析Sql，会大大降低Sql导致的线上事故）

15. select for update有什么含义，会锁表还是锁行还是其他。

select for update 含义

select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。

没用索引/主键的话就是表锁，否则就是是行锁。

最后

需要的朋友戳这里即可免费获取这份大牛的学习笔记哦~

select查询语句是不会加锁的，但是select for update除了有查询的作用外，还会加锁呢，而且它是悲观锁哦。至于加了是行锁还是表锁，这就要看是不是用了索引/主键啦。

没用索引/主键的话就是表锁，否则就是是行锁。

最后

需要的朋友戳这里即可免费获取这份大牛的学习笔记哦~

[外链图片转存中…(img-nb57gOjt-1626759520891)]