SQL优化进阶：读懂执行计划，告别慢查询焦虑

SQL优化进阶：读懂执行计划，告别慢查询焦虑

大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

你是不是也遇到过这种情况：一条SQL平时跑得飞快，某天突然慢得像蜗牛。你翻出慢查询日志，找到了那条SQL，但完全不知道它为什么变慢。加个索引试试？没用。改个写法试试？还是没用。最后只能重启数据库碰运气。

这种“凭感觉优化”之所以无效，是因为你缺少一份数据库的“自检报告”。这份报告就是执行计划。

执行计划是数据库在真正执行SQL之前，先给你看的一份“作战方案”——它告诉你打算用什么方式查数据、用哪些索引、预估扫描多少行、还要做哪些额外操作。学会看执行计划，你就能从“猜”变成“看”，优化不再是玄学。

下面我们拆解执行计划中最核心的五个字段，理解它们的含义，你就能快速定位慢查询的病根。

type：访问方式，性能的“红绿灯”

type表示数据库如何访问表中的数据。从最好到最差依次为： > const > > ref > range > index > ALL。

你可以把它理解成开车上路的效率等级：

诊断标准：看到ALL或index，基本可以判定索引设计有问题或没有可用索引。

：复合索引用了几层

对于复合索引(a,b,c)，告诉你实际使用了多少列。比如一个INT字段占4字节，DATE占3字节，按字符集算（通常每字符4字节，再加2字节长度标识）。如果索引定义总长是50字节，但只有4，说明只用了第一列。

这个判断不是靠背公式，而是通过对比索引定义和的数值，你就能知道查询条件是否命中了索引的前缀、有没有跳过中间列。如果偏小，往往是因为查询条件没写全索引列，或者违背了最左匹配原则。

rows：估算要扫多少行

rows是优化器根据统计信息估算的需要扫描的行数。它是一个相对值，不是精确值，但量级决定了查询成本。

诊断标准：rows越大，通常性能越差。如果rows接近全表总行数SQL优化进阶：读懂执行计划，告别慢查询焦虑，却还在用索引，说明索引选择性极低（比如只建在性别这类字段上）sql语言与数据库操作技术大全sql语言与数据库操作技术大全，优化器可能走错了方向。

：索引筛完后还剩多少

表示存储引擎返回的行中，满足剩余WHERE条件的比例。100%是最好的情况，意味着索引已经精准定位，不需要额外过滤；10%意味着索引只筛掉了90%，回表后还要再过滤掉大部分数据，往往是因为索引列选择性差，或者查询条件中有不在索引中的过滤字段。

诊断标准：低时，应考虑扩展索引把过滤字段也加进去，或者调整索引顺序。

Extra：额外的“小动作”

Extra列里藏着数据库在执行过程中需要做的额外操作，有些是好事，有些是坏事。

这些提示直接指向了优化方向：看到就去加GROUP BY列的索引；看到就去给ORDER BY列建索引；看到join 就去检查连接条件有没有索引。

为了让你更直观地理解这些字段如何配合，我们看一个简化版的诊断流程。

假设你有一条慢查询，执行后得到输出。你不需要逐字逐句分析，而是按顺序问自己三个问题：

第一问：type是什么？

如果是ALL或index，问题根源在访问方式太原始。大概率是没索引或索引没生效。先去检查WHERE条件涉及的列有没有索引，以及有没有隐式类型转换、函数包裹索引列等失效原因。

第二问：是否合理？

对照你创建的复合索引定义，看是否覆盖了你期望的列数。如果明显偏小，说明查询条件没用到索引的前缀，需要调整索引列顺序或补全条件。

第三问：Extra里有没有或？

如果有，说明GROUP BY或ORDER BY没有走索引。去检查这些列是否在索引中，以及索引顺序是否匹配排序要求。

这三个问题走完sql语言与数据库操作技术大全，80%的慢查询都能找到病因。剩下的20%往往和数据分布、统计信息陈旧有关，那时候再配合 TABLE更新统计信息，或者在测试环境用 看真实执行数据。

从执行计划到优化动作，核心逻辑不是堆砌索引，而是先读懂数据库给你的反馈，再有针对性地调整。type告诉你“怎么查”，告诉你“用了几列”SQL优化进阶：读懂执行计划，告别慢查询焦虑，rows和告诉你“代价多大”，Extra告诉你“额外负担”。把这五个字段串联起来，你就能在几十秒内判断一条SQL的健康度，并快速锁定问题。

下次遇到慢查询，别再盲目加索引了。先跑一遍，让数据库告诉你它需要什么。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~