企业官网建设流程全解析

1. 先从最直接的问题说起：EXPLAIN 到底能帮你解决什么

先说一个我自己经历过的场景。某天半夜，线上系统告警，某个查询接口响应时间从 200ms 涨到了 8 秒。当时第一反应是看慢查询日志，捞出来一条 SQL，是一条关联了 5 张表的统计查询。当时我做的第一件事不是去改代码，而是执行了一条 EXPLAIN，几秒钟后，问题就定位了：其中一个表走的全表扫描，扫描行数 300 多万行。加了索引之后，接口响应时间降到 300ms 以内。

这就是 EXPLAIN 的价值——它不直接帮你调优，但它能把 MySQL 执行 SQL 时的"内心活动"摊开给你看：用了哪张表、走没走索引、走了哪个索引、预计扫多少行、有没有临时表、有没有文件排序，全都写在那一张表里。你只有先看懂这张表，才知道 SQL 到底慢在哪，才知道该往哪个方向去优化。

这篇文章不跟你扯晦涩的源码级原理，就讲一件事：拿到一条慢 SQL 之后，怎么通过 EXPLAIN 输出结果快速定位瓶颈，以及怎么根据这些信息反推优化方案。适合被慢查询折腾过、想系统学会看执行计划的开发同学，也适合那些 EXPLAIN 字段能背出来但真遇到问题不知道怎么用的人。

说明：我用的环境是 MySQL 8.0，存储引擎 InnoDB。如果你还在用 MySQL 5.7，大部分内容同样适用，个别新特性我会单独标注。

2. EXPLAIN 是什么，为什么它叫"透视镜"

2.1 一条 EXPLAIN 命令能给你什么

EXPLAIN 的使用方式极其简单，在你原本要执行的 SELECT 语句前面加上 EXPLAIN 关键字，MySQL 会返回一张表格，描述这个查询的执行计划。它不会真正去执行这条 SQL，只是基于成本模型和统计信息，推算出一个执行方案。

EXPLAIN SELECT * FROM orders WHERE user_id = 10086;

返回结果有十几个字段，包括id、select_type、table、type、possible_keys、key、key_len、ref、rows、filtered、Extra等。每个字段各有各的含义，但要我说，真正需要投入精力去研究的，其实只有几个核心字段。那些次要字段知道怎么回事就行，真正决定你调优方向的，是type、key、rows、Extra这几列。

这里要先纠正一个常见的误区：EXPLAIN 的结果和真实执行结果之间是有偏差的。它告诉你的是 MySQL 优化器根据统计信息推算出来的计划，不是实际运行数值。所以rows是估计值，不是精确扫描行数。在绝大多数情况下这个估计值是靠谱的，但在统计信息过期或者有复杂查询的情况下，误差会明显变大。

2.2 不要只调 SQL，先看表结构和数据分布

以前我带过团队，很多同事拿到慢 SQL，第一反应就是改写 SQL 写法，比如把子查询改成 JOIN，把 OR 改成 IN，这样做有时候有效，但更多时候属于碰运气。

真正该做的是先跑一遍 EXPLAIN，看清瓶颈到底在哪个环节，再决定是改 SQL、加索引、改表结构，还是调整数据分布。这就像车坏了，你不能上来就换轮胎，你得先检查到底是轮胎的问题、发动机的问题，还是油路的问题。EXPLAIN 就是你用来排查的那个诊断仪。

有经验的工程师拿到慢 SQL 之后，执行 EXPLAIN 可能只需要 10 秒，就能判断出大概方向。这个过程不需要太多理论知识，靠的就是对各个字段含义和常见组合模式的熟悉程度。接下来我就按从"粗看"到"细看"的顺序，把这几个关键字段逐个拆开讲。

3. 核心字段逐个拆解：先看 type，再看 key，最后看 Extra

3.1 type 字段：访问类型，性能的第一道分水岭

type是 EXPLAIN 结果里最直观、最能说明问题的字段。它表示 MySQL 查找数据行的方式，从好到差大致是这样一个顺序：

最简单的判断标准：如果type是ALL，这就是一个危险信号，说明这条 SQL 在裸扫整张表。数据量只有几百条的时候无所谓，一旦到几百万条，必然出问题。type是index的情况属于比全表扫描好一点，但也没好到哪里去，因为它虽然不用回表，但还是要遍历整个索引，如果索引很大，一样慢。

举一个真实的例子。有一张用户行为日志表，数据量在 200 万行左右，有个查询是查某一天某个用户的行为记录：

EXPLAIN SELECT * FROM user_logs WHERE user_id = 12345 AND log_date = '2024-05-20';

我执行后发现type是ALL，说明没走索引，全表扫描。打开表结构一看，这张表只有一个主键索引和一个业务方自己加的单列索引idx_user_id。问题出在哪儿？user_id有索引，但log_date没有，优化器算下来觉得用idx_user_id还得回表过滤日期，代价可能不低于全表扫描，干脆直接扫表。

解决方式很简单：加一个联合索引(user_id, log_date)，把等值条件和范围条件一起覆盖。改动之后重新 EXPLAIN，type变成了range，key显示走了新索引，rows从 200 万降到了几百。这中间的差别，可以说就是天壤之别。

注意：type从ALL变成range或者ref，绝不仅仅是一个数字的变化。它代表的是 MySQL 从遍历整张表的聚簇索引，变成了在二级索引树上做 B+ 树查找，从线性复杂度变成了对数复杂度。数据量越大，差距越明显。

3.2 key 和 possible_keys：MySQL 实际用了哪个索引

possible_keys列出了 MySQL 优化器认为可能用到的所有索引，key是最终实际选择的索引。这两个字段看似简单，其实背后有很多值得琢磨的地方。

一个很常见的情况：possible_keys里有多个索引，但 MySQL 实际选择的那个索引不一定是最好的。MySQL 优化器是基于成本模型做选择的，它估算各个方案的 IO 成本和 CPU 成本，挑一个它认为最低的。问题在于，这个估算依赖统计信息，而统计信息可能不准确，或者被复杂查询条件干扰，导致选错索引。

我遇到过另一个有意思的现象：possible_keys是NULL，说明 MySQL 认为没有任何索引可用，或者它压根没考虑用索引。后者往往是因为你在索引列上做了函数运算或者隐式类型转换，导致索引失效。比如：

EXPLAIN SELECT * FROM orders WHERE DATE(create_time) = '2024-05-20';

如果create_time上建了索引，这个 SQL 也用不上，因为对索引列做了函数运算之后，B+ 树上存储的原始键值顺序已经被破坏，MySQL 没法直接走索引查找。正确的姿势是改成范围查询：

EXPLAIN SELECT * FROM orders WHERE create_time >= '2024-05-20 00:00:00' AND create_time < '2024-05-21 00:00:00';

这样type就能从ALL变成range，索引也能用上了。类似的场景还有在字符串字段上跟数字比较，导致隐式类型转换，MySQL 只能放弃索引。这些我后面在常见问题部分再展开说。

3.3 rows 字段：预估扫描行数，判断优化效果的核心指标

rows表示 MySQL 预计要读取的行数。这个数字越大，查询越慢。注意它只是一个估算值，真正的执行可能需要扫描更多或更少的行，但用它来做优化前后的对比还是非常有参考价值的。

很多初学者容易犯一个错误：只看type是不是从ALL变成了ref，忽略了rows的变化。实际上type是一类访问方式的定性描述，rows才是定量的指标。比如同样是ref类型的查询，rows=100和rows=10000，性能完全不是一个量级。前者可能几毫秒，后者可能几百毫秒。

我用 EXPLAIN 做优化的习惯是：优化之前先记录rows的数值，优化之后再跑一次对比。如果索引加对了，rows通常能下降一到三个数量级。这个下降幅度，比任何理论分析都有说服力。

3.4 Extra 字段：隐藏的执行细节，重点看几个关键词

Extra字段是整个 EXPLAIN 输出中信息量最大的字段，里面藏着很多执行细节。对调优来说，最关心的几个关键词是：

第一是Using temporary。出现这个，说明 MySQL 在执行过程中创建了临时表来辅助查询。临时表可能会被写到磁盘上，性能影响非常大。一旦在 EXPLAIN 里看到这个，就要重点排查是不是 GROUP BY 或 DISTINCT 用的字段没有索引，或者排序字段和分组字段不匹配。

我用一个实际例子说明。有一张订单统计表，业务上要按天统计订单数：

EXPLAIN SELECT order_date, COUNT(*) FROM orders WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY order_date;

如果order_date上有索引，这个 GROUP BY 可以借助索引的有序性直接完成聚合，不需要临时表。如果没索引，MySQL 就得先把数据找出来，存进临时表，再排序分组。执行计划里的表现就是Using temporary加Using filesort。

第二是Using filesort。这个字段表示 MySQL 需要对结果进行额外排序，但这里的 file 不是文件的意思，而是内存中的排序缓存不够时才会用到磁盘文件。不管是哪个，都意味着有额外的排序开销。如果要排序的字段有索引，排序可以直接复用索引顺序，就不会出现Using filesort。

第三个是Using index。这是最理想的标记之一，表示查询涉及的字段全部包含在索引中，不需要回表去查询聚簇索引。这种情况下，所有数据都能从索引树里取得，IO 开销大幅减少。这也是覆盖索引的价值所在。

第四个是Using where。这个字段表示在存储引擎层拿到的数据之后，还要在服务层再过滤一遍。它本身不算问题信号，但如果出现在ALL扫描的查询中，就说明很多行被读出来后又白过滤掉了，白白消耗了 IO。

看 Extra 字段的时候，我建议按这个优先级排查：先看有没有Using temporary，再看有没有Using filesort，然后看有没有Using index（覆盖索引）和Using where的组合。这几个字段的组合方式能告诉你整个查询的执行路径，比单个看字段要有用得多。

4. 实战步骤：一条慢 SQL 从定位到优化的完整过程

4.1 从慢查询日志中捞出一条 SQL

我现在的习惯是，每天的巡检第一步就是把慢查询日志打开看一眼。MySQL 开启慢查询日志的方法很简单，可以动态设置：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;

这样超过 1 秒的 SQL 会被记录到日志文件。线上环境建议把long_query_time设成 0.5 秒甚至更低，因为线上很多查询虽然只有 300ms，但调用频率很高，累计消耗也很惊人。

假设我从日志里看到了这样一条 SQL：

SELECT u.user_name, COUNT(o.order_id) AS order_count FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE u.created_at >= '2024-01-01' GROUP BY u.user_id ORDER BY order_count DESC LIMIT 20;

这是一条典型的分组统计查询，查的是今年每个用户的订单数量，取前 20 名。看起来逻辑不复杂，但线上已经跑了快 3 秒。这种带 LEFT JOIN 再加 GROUP BY 的查询，出现性能问题通常有几个可能的瓶颈：关联字段没索引、分组字段没索引、排序字段和索引顺序不匹配。

4.2 用 EXPLAIN 逐段定位瓶颈

我执行了 EXPLAIN：

EXPLAIN SELECT u.user_name, COUNT(o.order_id) AS order_count FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE u.created_at >= '2024-01-01' GROUP BY u.user_id ORDER BY order_count DESC LIMIT 20;

得到的结果大致是这样的结构（我简化了一些次要字段）：

看到这个结果，几个问题一目了然：

第一，users表全表扫描，120 万行直接裸扫，type是ALL。第二，Extra里出现了Using temporary和Using filesort，说明 GROUP BY 和 ORDER BY 都没有借助索引完成。第三，orders表这边倒是不错，type是ref，走了idx_user_id，还用了覆盖索引。

所以瓶颈基本锁定在users表的关联和分组上。u.created_at >= '2024-01-01'这个条件应该能用上created_at索引，但EXPLAIN显示possible_keys是NULL，说明这个字段上没有索引，或者有索引但被某种写法破坏了。

我去查看了一下users表结构，果然created_at字段上没有索引。更关键的是u.user_id是主键，按理说 GROUP BY 主键应该可以用到主键索引的有序性，但由于驱动表先做了全表扫描，顺序已经被打乱，优化器没法利用主键序，所以Using temporary还是出现了。

4.3 制定优化方案并验证

针对这个执行计划，我做了两件事：

第一件事：给users.created_at字段加上索引。这样 WHERE 条件里的范围查询可以走索引，驱动表的扫描范围从全表变成索引范围。

ALTER TABLE users ADD INDEX idx_created_at (created_at);

第二件事：调整 SQL 的写法。虽然 GROUP BY 在主键上，但因为ORDER BY order_count DESC跟索引顺序完全不匹配，所以无论如何都有Using filesort。这个排序本身没办法去掉，除非业务上接受不做排序，但那不现实。所以我能做的，就是把临时表这一层开销尽量降低。

改完表结构之后，我再跑一次 EXPLAIN：

这一次，驱动表users的type从ALL变成了range，rows从 120 万降到了 2300，Extra里的Using temporary也消失了，只剩一个Using filesort（因为排序本身无法避免）。真实执行时间从 3 秒降到了 600ms 左右。后来我又把users表的主键从user_id改成(created_at, user_id)这种带业务意义的主键是不可能的，所以我换了个思路，让排序也在索引里走，不过那又是另外一个话题了。

这个案例的核心价值在于：不是所有的慢查询都需要重写 SQL，很多时候给对字段加上索引，一切问题就迎刃而解。但前提是，你得先通过 EXPLAIN 看清每一步到底做了什么。

5. 进阶技巧：EXPLAIN 的多种形态和隐藏玩法

5.1 EXPLAIN ANALYZE：直接告诉你每一步真实花了多久

MySQL 8.0.18 引入了EXPLAIN ANALYZE，这个命令跟传统 EXPLAIN 最大的区别在于：它是真实执行 SQL，然后输出每一步的执行时间、扫描行数和实际开销。比如：

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 10086;

输出的结果是一棵嵌套的树状结构，每一行代表一个执行节点，里面有 actual time、actual rows、actual loops 等真实数据。比如actual time=0.215..0.235 rows=5 loops=1，意思就是这一步实际耗时 0.215ms 到 0.235ms，实际处理了 5 行，执行了 1 次。

跟传统 EXPLAIN 配合使用的时候，我的习惯是：先用传统 EXPLAIN 看执行计划的结构，定位可能的问题节点，再用 EXPLAIN ANALYZE 验证真实耗时，确认瓶颈到底在哪一步。传统 EXPLAIN 是"地图"，EXPLAIN ANALYZE 是"实时路况"，两者配合才能做到精准定位。

注意：EXPLAIN ANALYZE 会真实执行语句，所以线上使用要谨慎，尤其不要直接对写操作或者超大数据量的查询跑这条命令，否则可能放大线上压力。建议在压测环境或只读从库上操作。

5.2 格式化输出和 JSON 格式可视化

除了普通的表格输出，EXPLAIN 还支持EXPLAIN FORMAT=JSON，输出的结果是一个 JSON 对象，里面除了字段本身，还包含成本估算的详细拆分，包括cost、rows、prefix_cost这些信息。排错的时候可以用 JSON 格式配合可视化工具，把执行计划画成图，看得更直观。

MySQL 官方 Workbench 就有可视化执行计划的功能，执行 EXPLAIN 之后点击对应按钮，就能看到树状图形界面。如果你不用 Workbench，也可以用EXPLAIN FORMAT=JSON导出结果，配合在线 JSON 可视化工具或者自己写脚本解析，生成自定义的执行链路图。

图形化的好处是对新手特别友好，因为执行计划的树状结构一眼就能看清哪张表是驱动表、哪张表是被驱动表，执行顺序是什么。文字版虽然信息全，但初看时容易遗漏表之间的层级关系。

5.3 在 EXPLAIN 中使用通配符和分区表信息

EXPLAIN 加PARTITIONS选项会显示查询涉及哪个分区（MySQL 5.7 及之前需要额外加 PARTITIONS 参数，8.0 默认包含）。核对分区裁剪是否生效时特别有用。如果一张分区表上跑了查询，希望只扫描某个分区，但执行结果显示访问了全部 12 个分区，说明分区键没用上，需要检查 WHERE 条件里是否包含了分区键的等值条件。

再补充一个我常看的字段filtered。它表示存储引擎层返回的数据在服务层经过 WHERE 条件过滤后，剩余的比例。比如rows是 1000，filtered是 10%，意味着预计只有 100 行能通过过滤。这个字段在 JOIN 查询中能帮你判断被驱动表的连接条件是否被高效利用。

5.4 结合 optimizer trace 查看优化器为什么选这个索引

有时候你会看到 EXPLAIN 显示的key字段和你预想的不一样，明明有更合适的索引，优化器就是不用。这时候光看 EXPLAIN 是不够的，你需要查看 optimizer trace，看优化器的决策过程。

SET optimizer_trace = 'enabled=on'; SELECT * FROM orders WHERE user_id = 10086; SELECT * FROM information_schema.OPTIMIZER_TRACE; SET optimizer_trace = 'enabled=off';

OPTIMIZER_TRACE输出里包含了优化器对各个索引的访问成本估算对比，比如rows_estimation和considered_execution_plans等部分。通过这些信息，你能搞清楚优化器选择某个索引的具体逻辑。最常见的结论是：优化器认为某个索引选择性不高，回表成本太大，所以不选它。这其实是在告诉你——该加联合索引了，而不是怪优化器"傻"。

6. 高频坑位实录：处理过的真实问题与排查方法

6.1 看着有索引，为什么 EXPLAIN 还是走全表扫描

这是我在工作中遇到最多的一个问题。明明给字段加了索引，运行 EXPLAIN 却发现type是ALL。这种情况背后通常有五个原因。

第一个原因是索引列上用了函数或表达式计算，比如WHERE DATE(create_time) = '2024-01-01'或者WHERE price + 1 > 100，函数运算让索引失效。解决办法是把函数去掉，改成范围查询或者等值查询。

第二个原因是隐式类型转换。比如order_no是 varchar 类型，查询条件是WHERE order_no = 12345678（数字），MySQL 会把字符串隐式转换成数字，索引失效。解决办法是把查询参数改成字符串类型。

第三个原因是 LIKE 模糊查询以通配符开头，比如WHERE name LIKE '%张%'。这种写法无法利用 B+ 树索引的有序性，只能在索引上做全扫描或者干脆回表扫。如果业务允许，可以考虑改成WHERE name LIKE '张%'，这样还能走前缀匹配索引。

第四个原因是统计信息过旧。MySQL 依赖统计信息来决策是否使用索引，如果统计信息跟实际数据分布差异太大，优化器可能"误判"。解决办法是用ANALYZE TABLE重新收集统计信息。

第五个原因是优化器认为即使走索引也要回表太多次，成本比全表扫描还高。这种情况常见于表中大部分行的字段取值都相同，比如性别字段区分度太低，优化器经过成本计算后干脆选择全表扫描。

6.2 Using filesort 不应该出现的地方出现了

排序是慢 SQL 里另一个高频瓶颈。正常情况下，如果查询的 ORDER BY 字段跟索引的列顺序一致，就能直接利用索引的顺序，不需要额外排序。但如果你看到Using filesort，就要检查以下几点。

首先要看排序字段和索引字段的顺序是否一致。联合索引(a, b, c)可以支持ORDER BY a, b, c，但如果你写成ORDER BY b, a, c，顺序对不上，索引用不上。其次看排序字段的方向，全部 ASC 或全部 DESC 没问题，但如果有的字段升序有的字段降序，索引的有序性也无法完全利用。最后看 WHERE 条件里的等值条件是否让排序字段成为索引前缀的一部分。

比如联合索引(user_id, order_date)，对查询WHERE user_id = 100 ORDER BY order_date DESC，这个排序是可以用索引的，因为user_id已经定位成等值了，等于把order_date变成了索引的第一个动态列，索引的有序性可以被利用。

6.3 大表 JOIN 慢，重点看驱动表是谁

JOIN 查询中，MySQL 会选择一个表作为驱动表，按一定顺序读取数据。EXPLAIN 结果里的第一行是驱动表，第二行是被驱动表。一般原则是小表做驱动表，大表做被驱动表，这样可以减少被驱动表的访问次数。但如果驱动表选错了，性能会非常差。

我还是用ordersJOINusers的例子。如果被驱动表users的关联字段user_id没有索引，每一次关联都要全表扫描一次 users 表，代价不可想象。这时候 EXPLAIN 显示的信息最容易暴露问题——被驱动表的type往往是ALL，rows是几十万甚至上百万。

优化方案分两步：第一步保证被驱动表的关联字段有索引，这样 JOIN 才能走ref或者eq_ref。第二步用STRAIGHT_JOIN强制指定驱动表顺序，在特殊场景下手动干预优化器的选择。

6.4 索引都加了，rows 降到个位数了，还是慢

这种情况我也碰到过不止一次。EXPLAIN 显示type是ref，rows只有几十行，按道理应该很快，但实际执行还是几百毫秒甚至秒级。这时候问题往往不在 SQL 本身，而在于其他环节。

第一种可能是索引回表次数太多。虽然扫描了 50 个索引条目，但这 50 条数据分散在磁盘的不同页面上，回表查询聚簇索引需要做大量随机 IO。这种场景的解决办法是使用覆盖索引，把 SELECT 的列都包含在索引中，减少回表。

第二种可能是在 SQL 前面还有真正的瓶颈环节，比如网络传输、连接建立的开销、查询结果集太大导致排序和传输耗时长。EXPLAIN 只看执行计划，看不到网络和客户端处理环节。你可以用EXPLAIN ANALYZE看看哪一步真实耗时最高。

第三种可能是被下游占用了大量 CPU，比如这条查询本身不慢，但同一时刻有很多类似的查询并发执行，直接把数据库 CPU 打满了。这种情况就不是单条 SQL 的问题了，需要从全局的角度去分析和治理。

7. 从看懂到会用：我的一些个人习惯和参考建议

看 EXPLAIN 是一门熟能生巧的手艺。我见过有人把十几个字段全背下来，但遇到真实问题还是一筹莫展；也见过有人只懂type和rows两个字段，就能解决大部分线上问题。区别不在于知道多少，而在于有没有形成一套自己的排查流程。

我的习惯是这样的：拿到一条慢 SQL，第一步先看type和rows，快速判断有没有全表扫描或者扫描行数特别大的表。第二步看Extra，重点搜索Using temporary和Using filesort这两个关键词。第三步看key，确认优化器有没有用上预期的索引。第四步根据前几步的结果，决定是加索引、改 SQL 还是调结构。最后再用 EXPLAIN 验证优化效果，对比rows的变化。

在线上环境执行 EXPLAIN 的时候，我建议加上EXPLAIN FORMAT=JSON，导出的信息更完整，还能看到成本数据。如果用的是 MySQL 8.0，优先使用EXPLAIN ANALYZE做真实耗时验证，但注意别在高峰期对超大查询执行。

做索引优化时，多思考一下"这个索引能覆盖哪几个查询模式"，而不是每个查询单独加索引。联合索引建得好，一个索引能顶上几个单列索引。建得不好，不但占空间，还会拖慢写入速度。一个联合索引往往比三个单列索引更高效，因为 MySQL 一个查询只会选择一个索引，如果你的三个条件分别建了三个索引，最终也只能走一个，另外两个相当于白建。除非用索引合并机制，但那个就复杂了。

最后分享一个我踩过很多次坑之后总结出的原则：EXPLAIN 的结果只代表优化器的"预判"，不代表真实的性能全貌。它可能因为统计信息不准、成本模型误差等原因，给你一个不是最优的执行计划。所以，EXPLAIN 用来定位问题是利器，但最终效果还是要看实际执行时间的变化。你优化完 SQL 之后，一定要回到真实的执行时间上去验证，而不是只看 EXPLAIN 里几个字段变得好看了。