第4章 核心手术室：索引与查询优化

第 4 章 · 核心手术室：索引与查询优化

本章要回答的三个问题：B+ 树索引到底怎么组织数据，为什么能快、什么时候会失效？EXPLAIN 执行计划各列怎么读，如何从里面看出病灶？优化器自己会选路，我们还需要改写 SQL 吗？

为什么会有这一章

全书的病例里，七成以上在这间手术室结案。索引是把顺序扫描变成树查找的结构性提速，但"建了索引还是慢"的病例同样常见——函数包住索引列、隐式类型转换、最左前缀没对齐，这些都能让精心建的索引瞬间失明。会建索引只是半个医生，会读执行计划才是能上台的主刀。

读完能解决什么

• 能解释 B+ 树的结构与聚簇索引、二级索引、回表的机理
• 能逐列解读 EXPLAIN 输出并定位扫描量异常
• 掌握常见 SQL 改写手法与优化器的成本判断逻辑

各节怎么分工

先决条件

第 3 章的两层架构：知道执行器从引擎一行行取数，才知道 rows 这个数字为什么致命。

往下走到哪

单条查询治好了，第 5 章处理并发场景——多个事务挤在同一间病房时的锁与隔离问题。

手术室的结案率与漏诊

本章三节合起来是一套完整手术流程：4.1 讲病理，知道索引为什么快、怎么失效；4.2 讲影像，会拍会读执行计划；4.3 讲刀法，会改写会与优化器博弈。也要诚实记录手术室的漏诊清单——有些"慢"不归这章管：等锁造成的慢，片子上一片正常，要转 5.3 节急诊；缓冲池装不下热数据的慢，每条语句的计划都健康，要转 6.3 节调内存；从库重放落后的"读到旧数据"，根本不是查询问题，要转 7.3 节。手术台不是终点站，读片时保持"病灶不在扫描路径上"的警觉，是本章给读者留下的最后一课。

一个自我检验的方法：从自己项目的慢日志里挑三条真实语句，各写一份五栏诊断书（访问方式、扫描量、附加动作、驱动表、实测对照），写得出处方的去执行并复测。三条做完，本章的内容就从书上的知识变成了手上的技能。
最后给手术室立三条手术规矩，它们来自大量真实事故。规矩一，上线任何索引先评估写入代价：每次写入要维护几棵树、唯一索引是否有热点、大表建索引走什么流程。规矩二，每个"强制手段"都有档案：FORCE INDEX、STRAIGHT_JOIN 的使用必须附注释与复评日期。规矩三，优化必复测：改写前后的 EXPLAIN 与实际耗时都要留痕，没有复测的优化不结案。三条规矩立住，这间手术室就既能治病，也不会成为新病灶的来源地。
索引手术的特殊性在于它几乎不可逆地影响写入路径，所以手术室还有一条准入规矩：任何索引变更上线前，必须带上它的"病历附页"——针对哪些查询、预期扫描量变化、写入侧的评估结论。附页齐了才准上台，术后一周复诊确认预期兑现。这套流程初看繁琐，做顺了反而省事：它挡住了大半"为幻觉中的查询建索引"的无效手术，也让每一次索引膨胀都有据可查。手术室的公信力，靠的就是这样的流程而不是刀法本身。
手术室门口还有一块白板值得立起来：本周扫描量 Top 三的查询。它来自慢日志聚合，每周更新，团队例会过一遍。白板的价值不在记录而在凝视——扫描量最大的查询天然就是最该上台的病人，排着队按 4.2 的五栏诊断书逐台手术。很多团队的性能问题不是缺技术，是缺一块让问题排队、让手术排班、让结果可见的白板。这块白板立起来的那个月，通常就是慢查询工单开始下降的那个月。