做过几年MySQL性能优化的人几乎都有一个共同的习惯遇到慢SQL先不急着改代码而是把explain关键字打出来看一眼执行计划再说。这个习惯是怎么养成的因为它真的能一句话说清楚一条SQL为什么慢——是没用上索引是扫描行数太多还是排序在内存里硬扛这些信息explain都能给你答案。这篇文章不是给你背字段含义的而是把我这几年排查慢查询、优化线上SQL的实际经验整理出来每个字段到底该怎么看哪些信号一出现就得警惕还有几个踩过坑之后才知道的排查技巧。无论你是刚接触MySQL的新手还是写了好几年业务代码但没系统看过执行计划的后端开发这波内容应该都能让你少走不少弯路。1. 调优之前先把这条命令刻进脑子里1.1 一条SQL的执行计划到底在讲什么很多同学把explain当成一个“查看索引有没有生效”的工具这么理解不能说错但太窄了。一个完整的执行计划其实是MySQL优化器在拿到你的SQL之后经过语法解析、语义检查、代价估算、方案选择最终确定下来的一套执行策略。这个策略包括先读哪张表、按什么顺序读、走哪个索引、预计扫多少行、要不要回表、需不需要临时表、排序是在内存里做还是落磁盘。这些信息全部浓缩在explain输出的那一行行结果里。你完全可以把它当成MySQL在跟你交代“我打算这么执行这条SQL你看着办。”比如最简单的例子EXPLAIN SELECT * FROM orders WHERE order_no 20250701001;返回的每一列都是一条信息。有些字段一眼就能看懂有些字段必须组合起来才有意义。真正要训练的能力是面对一张执行计划表能在几秒内判断这条SQL是健康还是危险问题出在索引、写法、还是表结构。1.2 从慢查询到执行计划的完整链路先明确一个观念explain不是独立于慢查询之外的它恰好是慢查询排查链路里的第一环。正常流程是这样的——应用监控或慢查询日志里出现一条耗时超过阈值的SQL你先把它捞出来补全参数之后放到测试库或者直接在线库只读查询跑一遍explain。如果看到typeALL、rows几十万、Extra里挂着Using filesort那基本就能断定这条SQL该优化了。实际操作里我通常还会配合几个命令一起用SHOW CREATE TABLE table_name看表结构和现有索引SHOW INDEX FROM table_name看索引的基数和使用情况EXPLAIN FORMATJSON SELECT ...拿到更完整的代价信息MySQL 8.0以上会用EXPLAIN ANALYZE直接看真实执行耗时。这四条组合拳打下来绝大多数慢SQL的病因都能浮出水面。这里也提一句不要一上来就抱着执行计划猜先把表结构、数据量、索引情况摸清楚再看执行计划判断才会准确。数据量100万和1000万的表的优化策略完全不同。2. explain输出字段逐个拆解2.1 id、select_type和table先把SQL的骨架看清楚explain结果的第一行通常是id、select_type、table这三个字段。它们描述的是表在查询里的角色以及MySQL按什么顺序读这些表。id是查询编号数字越大的越先执行。如果是多表连接多个表的id相同说明MySQL打算在同一轮里去读这几张表读取顺序由优化器的连接顺序决定不是SQL里写的顺序。遇到带子查询的SQL子查询或派生表通常有独立的、更大的id先执行完再被外层引用。select_type常见的值包括select_type含义常见场景SIMPLE普通查询没有子查询和UNIONSELECT * FROM t WHERE id1PRIMARY外层查询含子查询时的最外层SUBQUERY子查询WHERE里的子查询DERIVED派生表FROM里的子查询UNIONUNION中的第二个及后续查询多段UNIONUNION RESULTUNION的结果合并多个UNION取并集看到DERIVED和UNION RESULT的时候要留个心眼。DERIVED意味着MySQL要把子查询结果物化成一张临时表如果这个子查询本身扫了很多数据临时表可能也很大很影响性能。MySQL 5.7以上的派生表合并优化能缓解一部分问题但也不是所有情况都能合并。table这一列就直白了显示的是访问的表名或别名。如果看到derivedN这种格式说明是idN的那张派生表得往上找对应行的查询逻辑。这三列组合起来你先画出一条SQL的“地图”有几张表参与、哪些是临时结果、执行顺序大致如何。后续再往下看访问路径和代价。2.2 type列访问类型一票决定快慢type列是执行计划里最先要看、也最应该重视的一列。它表示MySQL通过什么方式去定位表里的数据从快到慢的排序是system const eq_ref ref range index ALL这里我挑实际工作里最常见的几个讲。const通过主键或唯一索引定位到最多一行数据。这几乎是最理想的访问方式意味着MySQL能直接把那一行当成常量来处理比如WHERE id1。eq_ref多表连接时被驱动表通过主键或唯一索引等值匹配每一行只匹配到一条记录。这也是很健康的连接方式。ref通过普通二级索引的等值匹配定位多行比如WHERE statuspaid且status上有普通索引。这个效率也不错但要关注返回的rows是否过大。range索引范围扫描比如BETWEEN、、、IN、LIKE abc%等。范围扫描虽然没等值那么快但只要走索引而且范围不大性能通常可接受。index全索引扫描也就是遍历整棵索引树。比全表扫描好那么一丢丢但如果索引很大其实也好不到哪去。出现这个值要么是查询字段全在索引里覆盖索引但没走最优定位要么就是SQL写得有问题。ALL全表扫描这是危险信号。一旦在大表上看到ALL基本可以判定这条SQL是慢查询的常客。我在实战里有一条判断原则大表的查询type至少要到range才算及格目标是ref或const。如果优化半天还是ALL先别急着加索引看看是不是SQL本身的写法让索引失效了比如对索引列做了函数运算。2.3 possible_keys、key、key_len和ref索引从候选到落地possible_keys列出MySQL认为可能用到的索引key列出最终选定的索引。如果possible_keys有值但key为NULL说明优化器觉得这些索引都用不上这种情况常见于数据量太小或者索引选择性太差。key_len是很多人忽略但非常关键的一列它显示MySQL在索引里实际使用的字节长度。通过key_len能判断一条复合索引到底用到了几列。打个比方一张表有复合索引(province, city, district)字段都是varchar(20)用utf8mb4字符集如果key_len是82左右说明只用了province一列如果是164左右说明用了province city两列如果是246左右才说明三个列全部用上了。为什么是82utf8mb4下一个中文字符占4字节20个字符就是80字节varchar还有2字节长度前缀所以是82。如果字段允许NULL还会再加1字节标记。这个计算方式不复杂但查问题的时候是真的有用——很多同学以为复合索引建了就完事了实际SQL只用了最左边一列后面几列全靠排序或回表。ref显示的是索引等值匹配时参照的列或常量。比如const表示用常量去匹配db.t.user表示用了另一张表的user列去匹配。这三个字段通常要放在一起看possible_keys只是候选名单key才是最终选择key_len告诉你用了多少ref告诉你拿什么去匹配。结合起来就能还原出MySQL在索引层面的真实行为。2.4 rows和filtered代价估算的“晴雨表”rows是MySQL估算需要读取的行数。这不是精确值但对判断扫描代价非常有参考价值。我一般直接拿它和索引区分度做对比明明字段区分度很高但rows显示的估算行数占总行数比例很大说明这个索引没起到精准过滤的作用或者统计信息失真了。filtered是MySQL 5.1之后出现的字段表示存储引擎返回的数据经过Server层过滤后剩余多少百分比是符合查询条件的。比如rows显示1000filtered是10%意味着MySQL预计最终只有100行参与后续操作。filtered越低说明存储引擎层扫出来的数据处理效率越差这时候就要想能不能在索引层面就把过滤条件做得更精准。这两个字段是估出来的不用当作精确值但当执行计划跟你的直觉差别很大时比如明明数据分布很好rows却显示几十万那就得考虑执行ANALYZE TABLE刷新统计信息或者调整索引让优化器看得到更优的路径。2.5 Extra里的信号灯这些标记一出就得警惕Extra这一列是执行计划里的“彩蛋区”很多重要的危险信号都藏在这里。我挑几个最常遇到的Using index好消息表示查询用到了覆盖索引连回表都省了。你的索引里已经包含了需要的所有列直接扫索引就够了。Using where中性偏警示说明MySQL在存储引擎返回数据之后还要再用WHERE条件过滤一遍。注意不是所有Using where都有问题但如果配合typeALL一起出现那基本就是全表扫描之后在Server层做过滤。Using filesort这是个危险信号说明查询结果需要额外的排序操作。这个“filesort”不一定真的落磁盘但排序本身是有代价的数据量一大就会特别明显。要是发现排序字段和WHERE条件不在同一个索引里就要考虑增加或调整索引让B树天然有序把filesort消掉。Using temporary更危险说明MySQL创建了临时表来辅助查询。常见于GROUP BY、DISTINCT、UNION以及某些ORDER BY场景。临时表要么在内存要么落磁盘无论哪种代价都不小。Using index condition表示用了索引下推ICPMySQL能把部分WHERE条件交给存储引擎层过滤减少回表次数这其实是优化生效的表现。Range checked for each record出现这个意味着连接查询时对被驱动表没法用固定索引可能每一行都要重新评估。这是个性能隐患需要留意。我的习惯是一条SQL如果同时出现ALL、Using filesort、Using temporary别犹豫直接进优化流程。3. 实战用explain定位慢SQL3.1 排查慢SQL的标准姿势工具讲完了接下来就是实战。我一般按下面这套流程走第一步从慢查询日志或监控平台拿到慢SQL。第二步补全SQL里的具体参数因为不同参数值可能产生完全不同的执行计划这点很重要。第三步在测试环境尽量恢复表结构和数据量或者直接在只读实例上跑explain。第四步逐列观察执行计划定位问题点。举一个之前处理过的订单查询例子。原始SQL大概长这样SELECT order_id, user_id, total_amount FROM orders WHERE status paid AND create_time BETWEEN 2025-06-01 AND 2025-07-01 ORDER BY create_time DESC LIMIT 20;执行计划里看到typeALL、rows800000、ExtraUsing filesort。对这个几百万行的表来说每次查询全表扫描加排序不慢才怪。检查表结构发现有一个(status, create_time)的旧索引。按道理这个索引应该能走范围扫描为什么执行计划没用呢因为插入了大量新订单之后统计信息没跟上优化器对“已支付订单数量”的估算失真觉得反正都要扫很多行干脆全表扫。这时候执行一次ANALYZE TABLE orders;让统计信息更新后再跑explain索引就正常用上了type变成了rangerows降到几千Extra里的Using filesort也消失了。这个例子说明一个很核心的道理索引没变SQL没变统计信息变了执行计划就能差出几十倍。3.2 三个真实踩过坑的优化案例第一个案例是索引失效的典型日期函数包裹索引列。某报表系统有一条SQL要查最近30天的数据SELECT * FROM payments WHERE DATE(create_time) DATE_SUB(CURDATE(), INTERVAL 30 DAY);乍一看没问题但explain结果显示typeALL扫了全表。原因是DATE(create_time)对列做了函数运算索引就失效了。改成范围比较之后就恢复正常SELECT * FROM payments WHERE create_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND create_time CURDATE() INTERVAL 1 DAY;这可能是优化里遇到最多的问题。记住一句话索引列放在比较符的左侧没问题但绝不要对索引列做函数或运算否则数据库就不知道怎么用B树帮你定位了。这就像图书馆按书名的首字母做了索引你却问“书名首字母的ASCII码能被3整除的书有哪些”再好的索引也帮不上忙。第二个案例是隐式类型转换。业务表里的手机号字段是varchar(11)SQL却用数字去查SELECT * FROM users WHERE phone 13800138000;explain一看typeALL。因为MySQL把字符串列和数字比较时会把列值转换成数字再比这本质上也是对索引列做了隐式函数操作索引自然失效。改成字符串写法后SELECT * FROM users WHERE phone 13800138000;执行计划立刻变成ref问题解决。排查这类问题最直接的方法就是对比字段类型和查询参数类型。第三个案例是分页深偏移。一个后台列表页分页到了第10000页SQL长这样SELECT * FROM orders ORDER BY id LIMIT 200000, 20;explain显示typeALL因为MySQL要先把前二十万行查出来扔掉再返回最后20行。即使走主键索引偏移量太大了也不划算。解决方案是“延迟关联”先只查主键再回原表取完整行SELECT o.* FROM orders o INNER JOIN ( SELECT id FROM orders ORDER BY id LIMIT 200000, 20 ) t ON o.id t.id;内层子查询只需要在主键索引上扫描不需要回表取整行代价小得多整体速度在原地提升了不止一个量级。这也是执行计划里能明显看出差异的场景前者的rows可能几十万后者的子查询部分typerange或index实际扫描行数被大大压缩。4. 常见问题与排查技巧实录4.1 加了索引却不用到底为什么这是初学者问得最多的问题。明明possible_keys里有索引key却是NULL或者type还是ALL一头雾水。根据我的排查经验常见原因按频率排序大概是查询条件对索引列做了函数、运算或隐式类型转换索引选择性太低优化器认为走全表比走索引更快比如性别字段上的索引统计信息过期上面订单的例子就是这个原因复合索引没满足最左前缀原则优化器判断数据量太小全表扫描成本更低。遇到这类问题我的处理顺序是先SHOW INDEX确认索引字段真实存在再EXPLAIN FORMATJSON看优化器的成本计算实在不行就用FORCE INDEX临时指定索引来验证。注意FORCE INDEX只是验证手段线上不建议长期使用因为数据分布变了之后强制索引可能变得更差。另外要提醒一句不要以为索引建得越多越好。每个索引都会占用空间还会拖慢写入速度。一个表的索引数量控制在五到六个以内单条SQL用到的索引最多也就一两个多了纯属浪费。4.2 用好EXPLAIN FORMATJSON和EXPLAIN ANALYZE如果觉得普通explain给的信息不够可以试试EXPLAIN FORMATJSON它会输出一份结构化的JSON里面包含每个步骤的预估成本EXPLAIN FORMATJSON SELECT * FROM orders WHERE status paid;JSON里有一个cost_info部分包含了read_cost、eval_cost、prefix_cost等字段。这些成本值覆盖了CPU、IO、内存的估算能帮你看清楚优化器为什么选这条路径。对比两个不同写法的JSON成本比单纯看rows直观得多。MySQL 8.0.18之后还有更强的EXPLAIN ANALYZE它会把SQL真正执行一遍然后告诉你每一步实际耗时、实际行数、循环次数EXPLAIN ANALYZE SELECT * FROM orders WHERE status paid;输出里能直接看到类似这样的一段信息- Index range scan on orders using idx_status (actual time0.123..1.432 rows2000 loops1)actual time就是真实执行耗时rows是实际返回行数。这个工具用来确认到底哪个阶段慢、哪个阶段循环次数太多效果非常直观。但有一点必须注意EXPLAIN ANALYZE真的会执行SQL涉及写操作或有副作用的语句不要随便用生产环境执行前也必须确认影响面。4.3 排查执行计划时容易忽略的几个细节先说SHOW WARNINGS。执行完EXPLAIN之后紧接着执行SHOW WARNINGS可以看到MySQL重写后的SQL。有时候你会发现它背后把你写的SQL改写成了完全不同的样子比如子查询被转成了连接或者谓词被下推了。搞清楚优化器实际执行的“译文”比纠结自己写的“原文”更重要。再者注意字符集和排序规则。两表关联时如果字符集不一致MySQL可能无法直接用索引或者需要做隐式转换。比如一张表utf8mb4另一张表latin1连接条件上的列索引就废了。执行计划里看到typeALL或者Extra里出现奇怪的转换信息去检查一下两表的字符集。还有一个容易被忽略的点是NULL值。索引列如果允许NULL在IS NULL、IS NOT NULL这类查询里优化器处理方式会不一样key_len也会比非空字段大1。实际开发中如果没有特殊需求尽量把字段设置为NOT NULL并给默认值这不光让索引更紧凑也让执行计划更稳定。4.4 执行计划也会“说谎”别盲信最后分享一个可能颠覆新手认知的体会执行计划是估算不是事实。rows是估算值filtered是估算百分比cost的成本模型跟真实环境存在偏差。这意味着同一条SQL在数据量不同、统计信息不同、内存状态不同的机器上执行计划可能完全不一样。正确姿势是把它当成决策参考而不是绝对真理。有一种典型场景是优化器明明选了一个看起来很差的执行计划但真实执行并不慢。原因可能是小表连接时哪种方式差距都不大。反过来也有执行计划看着挺好实际跑起来却特别慢。这种时候就要用EXPLAIN ANALYZE看真实耗时或者用OPTIMIZE_TRACE追踪优化器的决策过程。所以我在带人排查慢SQL的时候总会强调explain解决的是“定位问题”优化方案要结合业务、数据分布、索引结构综合判断。一条SQL慢到底是索引问题还是写法问题是统计信息问题还是数据分布问题先让执行计划告诉你“是什么”再决定“怎么改”。我自己当初踩过最大的坑就是拿到执行计划后光盯着type看看到ALL就叫嚣着要加索引结果几个索引都加完依然慢。后来才明白type是结果病因往往藏在key_len、rows、Extra的组合里。把每个字段的意义串起来看诊断才算完整。这一套方法用熟了之后排查慢SQL的速度会快上很多希望你也能从中受益。