一句话答案

MySQL 查询流程：连接器→分析器（语法）→优化器（执行计划）→执行器→存储引擎（InnoDB/MyISAM），插件式架构。

核心要点

B 树（B-tree）vs B+ 树：

维度	B 树	B+ 树
数据存储	非叶子节点也存数据（key + value）	只有叶子节点存数据，非叶子只存 key
叶子节点	不相连	双向链表相连
查询单条记录	可能在非叶子节点命中，略快	必须到叶子节点，路径固定
范围查询	需要回溯树（中序遍历），效率差	叶子链表直接顺序扫描，效率高
单节点存储 key 数量	少（要存 value，占空间）	多（只存 key，更矮更胖）
磁盘 IO 次数	相对多	相对少（树更矮，层数少）

MySQL 选 B+ 树的核心理由：

1. 范围查询高效（MySQL 最常见的查询类型）

• WHERE age BETWEEN 18 AND 30 → 找到 18 的叶子节点，沿链表扫描到 30，一次 IO 序列
• B 树做范围查询需要多次回溯，效率差

2. 树更矮，IO 次数少

• InnoDB 页大小 16KB，B+ 树非叶子节点只存 key（8 字节 bigint）和指针（6 字节）
• 每页可存约 16384 / (8+6) ≈ 1170 个 key
• 三层 B+ 树可存约 1170 × 1170 × 16 ≈ 2200 万条数据，只需 3 次磁盘 IO

3. 查询性能稳定

• B+ 树所有数据在叶子层，任何查询的路径长度相同，性能稳定
• B 树数据分布不均，性能抖动

4. 叶子层顺序 IO，友好磁盘预读

• 全表扫描时叶子链表顺序读，接近顺序 IO，比 B 树的随机访问快得多

追问与易错

追问方向：

• 查询缓存为什么被移除？
• 连接线程和线程池关系？
• Plugin 架构的好处？

易错点：

• ❌ MySQL 8.0 还有查询缓存——已移除
• ❌ 混淆 Server 层和引擎层

💡 记忆锚点

MySQL 查询像餐厅点餐流程：前台接待（连接器）、看菜单拼写对不对（分析器）、选最省钱的做法（优化器）、通知后厨开做（执行器）、后厨用什么灶台做菜（存储引擎）。存储引擎是插件式的，换灶台不用改前厅流程，InnoDB 是默认的全能灶台。