慢SQL优化实战：从执行计划到索引设计的全流程排查

我看过太多人一听到慢 SQL，第一反应就是“加索引”。这个思路不能说错，但很容易把一个系统的性能拖进更深的坑。上个月我处理过一条线上慢查询，单次执行将近 8 秒，慢查询日志里半小时内累积了几百次。表面看 SQL 确实简单，就是一张大表按条件过滤后取订单数据，可问题恰恰出在索引和 JOIN 顺序的配合上。我最初也试过直接加索引，结果执行计划根本没选它，反而因为索引维护成本把写入拖慢了。

这类问题处理多了之后，我沉淀了一套自己的排查流程：先看慢日志确认瓶颈在哪一层，再用执行计划定位扫描路径，最后才是动手改写 SQL 或者调整索引。今天我把这套流程完整还原出来，里面会用几个我真实处理过的 SQL 优化实例做拆解，包括深分页、OR 条件索引失效、函数运算导致无法命中索引，以及并行 SQL 优化到底应该用在什么场景。如果你是后端开发、DBA，或者正在处理接口超时但不知道从哪下手，这篇应该能给你一条清晰的排查主线。

1. 拿到一条慢 SQL，我先看什么：监控与分级

很多团队定位慢 SQL 的方式是“线上报错了再登录数据库查一下”，这其实已经晚了。慢 SQL 优化的第一步不是改 SQL，而是建立能持续观测的机制，否则你连“哪条 SQL 慢、慢了多少次、影响哪些接口”都答不上来。

1.1 慢查询日志是全量事实

MySQL 的慢查询日志是最直接的线索来源。线上环境一般会把阈值调整到 1 秒以内，而不是默认的 10 秒，否则很多影响体验的查询根本不会被记录。你可以在 MySQL 配置文件中加入：

ini复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 1
log_queries_not_using_indexes = 0

log_queries_not_using_indexes 这个参数我建议谨慎开启。它会把所有没走索引的查询都记录进来，在小表居多的系统里会产生大量噪音日志，反而淹没了真正需要关注的慢查询。我见过有人开完之后日志文件每小时涨几个 GB，最后只能紧急关掉。

慢日志里每一行关键信息都很重要，尤其是下面这几项：

我处理过的案例里，有相当一部分初看是“慢 SQL”，实际看 Lock_time 占掉大半，根因是行锁竞争，那 SQL 本身改不改都不解决核心问题。

1.2 先分清是真慢还是偶尔慢

拿到一条慢 SQL 之后，别急着 EXPLAIN，先把它出现的时间规律拉出来看。如果只在每天凌晨某段时间出现，很可能是定时任务和核心业务在抢资源；如果只出现在每周一大促流量高峰，那要考虑连接池和缓存命中率；如果没有任何规律，全天都在出现，那才是 SQL 本身的设计问题。

我自己习惯把慢日志里的 SQL 按小时聚合，统计出现次数和平均耗时。一个非常实用的经验是：同样的 SQL 偶发慢和持续慢，处理策略完全不同。偶发慢可能是 Buffer Pool 冷启动、磁盘 IO 抖动或者备库延迟导致；持续慢则往往是执行计划已经走偏，或者数据量增长超出了当初的设计水位。

1.3 同类慢 SQL 合并，按“综合损失”排优先级

优化资源是有限的，所以我会把慢日志里的同类 SQL 先做合并。不同业务系统慢日志格式不一样，但逻辑上都可以按 SQL 模版去重，也就是把参数值替换成占位符之后归组，然后算一个综合损失值：

综合损失 = 平均执行时间 × 单位时间出现次数

这个值越大，优先处理的等级越高。很多时候一条执行 2 秒的 SQL 如果每秒跑几十次，比一条执行 30 秒但每天只跑一次的分析 SQL 对系统伤害更大。前者会持续占满数据库连接，最终拖垮整个实例；后者虽然单次痛苦，但有充足的时间窗口去处理。

分级之后，我们再对每一条慢 SQL 做执行计划层面的检查。这也是下一章要展开的部分。

2. 从执行计划开始一次系统排查

执行计划是数据库优化器给出来的“执行路线图”。拿到慢 SQL 先别猜，用 EXPLAIN 看优化器实际打算怎么跑，这一步能省下大量试错时间。

2.1 EXPLAIN 里的每个核心字段都在说什么

MySQL 的 EXPLAIN 输出有几个字段需要特别养成条件反射级的敏感度：type、key、rows、Extra。

type 是访问类型，性能从好到差大致是：system > const > eq_ref > ref > range > index > ALL。ALL 代表全表扫描，index 代表扫了整棵索引树，这两个在慢 SQL 里出现时通常意味着需要优化。range 是索引范围扫描，在业务查询里已经算不错的状态。

rows 是优化器预估需要扫描的行数，Extra 里则会出现一些特殊标记。这里我提前说一个最常误导新人的点：Using filesort 不代表在磁盘上排序，它只是说明 MySQL 需要额外做一次排序操作，可能在内存中完成，也可能落盘。出现这个标记时，优先考虑排序字段是否和索引顺序一致。

下面是一个典型的执行计划片段，我故意保留了这个案例原本的样子：

text复制+----+-------------+-------+------+---------------+------+---------+------+---------+----------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra          |
+----+-------------+-------+------+---------------+------+---------+------+---------+----------------+
|  1 | SIMPLE      | order | ALL  | NULL          | NULL | NULL    | NULL | 1023458 | Using where;    |
|    |             |       |      |               |      |         |      |         | Using filesort  |
+----+-------------+-------+------+---------------+------+---------+------+---------+----------------+

这张表扫描行数 100 万以上，还有额外的排序操作。看到这种执行计划，SQL 快得起来才奇怪。更麻烦的是，possible_keys 是 NULL，说明优化器连候选索引都没找到，这时候你要检查的不是索引好不好，而是 SQL 的过滤条件是否真的能被索引利用。

2.2 排查时重点回答三个问题

我拿到任何一条慢 SQL，都会强制自己回答三个问题：它扫描了多少行？它有没有反复回表？它有没有做额外的排序或临时表操作？

扫描行数和使用索引并没有绝对关系。有时候执行计划显示走了索引，但 rows 依然有几十万，比如范围查询扫了索引中大量数据，然后还要回表逐行读取完整记录。这种场景下，我们真正要做的是缩小扫描区间，或者尝试覆盖索引。

回表的问题更隐蔽。InnoDB 的二级索引只保存索引字段和主键值，如果你查询的列不在索引里，每命中一条二级索引记录，都需要根据主键回聚簇索引查一次完整行。当命中量从几百条涨到几万条时，回表开销会线性放大。

排序和临时表的问题通常在 Extra 里体现。如果看到 Using temporary; Using filesort，意味着这条 SQL 不仅要排序，还可能在内存临时表中缓存中间结果。能避免就尽量避免，因为临时表一旦超过内存限制会落到磁盘，那速度就是断崖式下跌。

把这三个问题回答完，一条慢 SQL 的核心病理基本就清楚了。下一步才轮到动手和改写。

2.3 定位时间到底消耗在哪个执行阶段

EXPLAIN 看到的是路径，但路径正确不代表执行快。有些 SQL 明明执行计划很漂亮，结果跑出来还是慢，这时候需要用 profiling 看时间分布：

sql复制SET profiling = 1;
-- 执行这条慢 SQL
SHOW PROFILE FOR QUERY 1;

输出里能看到 executing、Sending data、Statistics 等阶段各自占了多少时间。如果时间主要集中在 Sending data，说明大部分消耗在存储引擎读取和回表上；如果集中在 executing，则可能是优化器选择的问题；如果是 Statistics 阶段耗时长，常见原因是统计信息过期。

从 MySQL 8.0 开始，SHOW PROFILE 已经被标记为废弃，官方推荐用 performance_schema.events_statements_history_long 来做更细粒度分析。不过在实际排查中，SHOW PROFILE 在 5.7 环境里仍然非常好用，我大多数时候还是先开着它看一眼阶段分布，再决定要不要往更深的地方挖。

有了前面这些准备，我来完整拆解三个我很常见的慢 SQL 优化案例，每个案例都包含“为什么慢”到“怎么改”的完整链路。

3. 三个真实场景的优化拆解

既然是讲 SQL 优化实例，那必须落到能直接抄作业的写法上。下面三个场景是我在业务系统里反复遇到的类型，也是慢 SQL 问题的高发地带。

3.1 深分页：LIMIT 翻页越深越慢

第一个场景非常典型：后台管理系统的订单列表，用户一直往后翻页，翻到很后面的时候接口突然超时。SQL 大致长这样：

sql复制SELECT id, order_no, user_id, amount, status, create_time
FROM user_order
WHERE user_id = 12345
ORDER BY id DESC
LIMIT 500000, 20;

这条 SQL 的执行逻辑和大多数人想的并不一样。它不是先找到第 50 万条之前的数据跳过，而是从第 0 条开始，把前 500020 条记录全部取出来，然后丢掉前 500000 条，只返回最后 20 条。这就意味着，即使你只需要 20 行数据，数据库也必须扫描并排序 50 万行以上。页数越深，扫描范围越大，耗时随之线性上涨。

我第一次处理这个场景时，第一反应是给 user_id 和 id 建联合索引，但执行计划确实走了索引，rows 依然很大，问题并没有解决。因为索引解决的是 where 条件的快速定位，解决不了“跳过前 N 行”带来的无谓扫描。

真正的解法有两个方向。第一个是延迟关联，核心思路是先通过覆盖索引拿到需要返回的主键 ID，再用主键回表取完整行：

sql复制SELECT t.id, t.order_no, t.user_id, t.amount, t.status, t.create_time
FROM user_order t
INNER JOIN (
    SELECT id
    FROM user_order
    WHERE user_id = 12345
    ORDER BY id DESC
    LIMIT 500000, 20
) tmp ON t.id = tmp.id
ORDER BY t.id DESC;

子查询里只查询主键，(user_id, id) 联合索引就能覆盖整个子查询，避免了提前回表扫描 50 万行完整数据。外层再通过主键精确关联，只会对 20 行数据做回表，扫描量直接下降几个数量级。

第二个思路更适合面向 C 端的场景：把“页码深翻”改成“基于游标翻页”。也就是说，前端不再传页码，而是把上一页最后一条数据的 id 传回来，SQL 改成：

sql复制SELECT id, order_no, user_id, amount, status, create_time
FROM user_order
WHERE user_id = 12345
  AND id < 上一页最后一条记录id
ORDER BY id DESC
LIMIT 20;

这种写法彻底绕开了 offset，每次查询都能通过索引直接定位，不管翻了多深，耗时都稳定在几十毫秒以内。代价是用户不能再随机跳转到任意页，但绝大多数真实业务并不需要这种跳跃翻页。

3.2 OR 条件把优化器逼到死角

第二个场景也很经典：一条 SQL 明明每个单条件都能走索引，合在一起之后反而全表扫描。比如下面的例子：

sql复制SELECT id, order_no, status, expire_time
FROM coupon
WHERE status = 0
   OR expire_time > NOW();

你单独跑 WHERE status = 0，执行计划走的是 status 索引；单独跑 WHERE expire_time > NOW()，也能走 expire_time 索引。但两个条件用 OR 一连接，优化器懵了，因为它需要在两棵索引树里分别查找，再合并去重，代价评估往往比全表扫描还高。最终执行计划很可能出现：

text复制+----+-------------+--------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table  | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+--------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | coupon | ALL  | status,expire | NULL | NULL    | NULL | 800000  | Using where |
+----+-------------+--------+------+---------------+------+---------+------+---------+-------------+

解决思路其实很朴素：既然优化器处理不了，那就让每一条分支自己去走自己最擅长的索引，最后再合并结果。最常见的手段是把 OR 改写成 UNION：

sql复制SELECT id, order_no, status, expire_time
FROM coupon
WHERE status = 0

UNION

SELECT id, order_no, status, expire_time
FROM coupon
WHERE expire_time > NOW()
  AND status != 0;

这里有一个容易忽略的细节：第二段查询必须加上 status != 0，否则 UNION 自带去重没问题，但如果两个集合都包含 status = 0 且 expire_time > NOW() 的记录，第一段已经取出来了，第二段再扫描也没意义，白白增加一次索引扫描。加条件本质是让查询集合互斥，减小第二段扫描量。如果确认两个分支不可能有交集，或者业务上允许重复结果，也可以直接用 UNION ALL，省掉一次去重排序。

3.3 对索引字段做函数计算，索引白加

第三个场景是完全从代码审查里揪出来的。业务方反馈某个报表页越来越慢，我看了 SQL：

sql复制SELECT user_id, SUM(amount)
FROM payment_order
WHERE DATE(create_time) = CURDATE()
GROUP BY user_id;

这 SQL 的语义很明确：查今天所有用户的支付总额。问题出在 DATE(create_time) 这个写法上。当你在索引字段上套了函数，MySQL 无法直接利用 B+ 树的有序性进行范围定位，每一行都要先算一遍 DATE(create_time) 再去比较，索引等于白建。它已经退化成全索引扫描。

解决方案是改写成范围条件，让索引可以直接定位：

sql复制SELECT user_id, SUM(amount)
FROM payment_order
WHERE create_time >= CURDATE()
  AND create_time < CURDATE() + INTERVAL 1 DAY
GROUP BY user_id;

改写之后，优化器能对 create_time 索引做 range 扫描，只读取当天的数据，扫描量直接和当天产生的数据量挂钩，而不是和历史全部数据量挂钩。

要是实在没办法避免函数操作，比如业务确实需要按月份汇总，那可以优先考虑把月份作为冗余字段存储，或者从 MySQL 8.0 开始使用函数索引。但我个人不推荐一上来就上函数索引，因为它会增加写入开销，而且对 SQL 写法约束依然很强，能通过范围改写解决的，尽量先改 SQL。

类似的隐式类型转换也要注意。如果 user_id 是 varchar 类型，SQL 里却传了数字 user_id = 123456789，MySQL 会先把字段值转成数字再比较，同样会让索引失效。要避免这种问题，在应用层绑定参数时就应该确保类型完全一致。

这三个场景解决之后，我还要说一个经常让人心态崩溃的情况：明明加了索引，为什么执行计划就是不选它？这个问题的答案往往和索引本身的性质有关。

4. 索引加了还是慢：那些容易翻车的“伪优化”

我曾经花了一下午调一条 SQL，加了索引、删了索引、又加回去，执行计划纹丝不动，依然是全表扫描。后来才明白，不是索引没用，而是这条 SQL 的字段组合方式让这个索引根本帮不上忙。

4.1 联合索引的顺序，决定了过滤力度

单个字段的等值查询，建单列索引就够了。但业务里的查询往往同时带多个过滤条件，这时候单列索引就显得很笨拙。比如：

sql复制SELECT order_no, amount
FROM user_order
WHERE user_id = 1
  AND status = 2
ORDER BY create_time DESC;

如果只有 user_id 的单列索引，数据库定位到该用户的所有订单之后，还要在内存里过滤 status，再对 create_time 排序。数据量大时，排序和回表会成为新的瓶颈。

更合理的做法是建联合索引 (user_id, status, create_time)。这里字段顺序非常关键：等值条件 user_id 和 status 放前面，排序字段 create_time 放最后。这样索引既能用来定位用户和状态，又能天然按时间倒序提供数据，省掉排序。

联合索引的“最左前缀”原则我就不再赘述了，但有个陷阱值得提醒：当一个查询同时有等值条件和范围条件时，范围条件右边的索引字段通常无法用于过滤。比如联合索引 (a, b, c)，查询条件是 a = 1 AND b > 100 AND c = 2，那 c 就很难被利用到。所以在设计联合索引时，应该把等值字段放在范围字段前面。

4.2 回表过多的时候，考虑覆盖索引

另一个“索引走得好但还是很慢”的典型原因，是回表行数太多。假设你有索引 (user_id, status)，查询是：

sql复制SELECT order_no, amount
FROM user_order
WHERE user_id = 1 AND status = 2;

二级索引只包含 user_id、status 和主键 id，查询还需要 order_no 和 amount，于是每命中一条索引记录，都要根据主键回聚簇索引取完整行。如果这个用户有几千条订单，就要回表几千次。

这种场景最直接的优化是扩大索引字段，把查询需要的字段都包含进来，形成覆盖索引：

sql复制ALTER TABLE user_order ADD INDEX idx_user_status_order (user_id, status, order_no, amount);

此时查询需要的所有列都在索引中，执行计划的 Extra 里会出现 Using index，数据库可以直接扫描索引返回数据，不用再回表。代价是索引体积变大、写入变慢，所以覆盖索引主要用于高频查询，不能顺手给所有查询都配一套。

4.3 索引选择性太低，优化器会主动放弃

还有一种情况非常反直觉：索引明明是存在的，可优化器看了一眼统计信息，决定不用。最常见的原因是索引选择性太低。比如一张用户表里有 gender 字段，只有“男/女/未知”几个取值，你建一个 (gender) 索引，优化器发现通过这个索引过滤之后还要回表读取一大半数据，那还不如直接全表扫描来得快。

索引选择性的通俗理解就是：这个索引字段的不同值占比。不同值越多、选择性越高，索引价值越大。可以用以下 SQL 看字段区分度：

sql复制SELECT COUNT(DISTINCT user_id) / COUNT(*) AS selectivity
FROM user_order;

比值越接近 1，说明字段区分度越好。在生产环境，如果你发现自己建的索引压根没被用到，优先跑一下这个统计，不要急着强制走索引。强制索引在数据分布变化后很容易翻车，属于最后的手段。

另外，如果数据表的统计信息长期没更新，优化器也可能做出很离谱的判断。此时可以先执行 ANALYZE TABLE user_order; 刷新统计信息，再看看执行计划是否有变化。我遇到不止一次，刷新统计信息之后，执行计划自己就恢复正常了，SQL 一句话没改，性能问题直接消失。

索引层面的事情处理完，我们再回到标题里提到的“并行 SQL 优化”。这个词在实际工作中经常被误用，我用一节专门把它讲清楚。

5. 并行 SQL 优化到底解决什么问题

很多人在 SQL 变慢之后会想到用并行来提速，但并行并不是一条简单易用的慢 SQL 解药。我把它单拎出来，是因为它的适用边界比很多人想象中要窄得多。

5.1 先搞清楚并行执行的工作模式

并行 SQL 优化的核心思想，是把一个原本串行执行的大查询拆分成多个互不依赖的子任务，由多个工作线程同时执行，最后汇总结果。它的理论收益近似于“单个查询时间除以并行度”，但现实中受磁盘 IO、CPU 核心数、内存带宽以及数据倾斜程度的限制，很难做到线性加速。

不同数据库的实现方式差异很大。MySQL 8.0 官方版本对单条 SQL 的并行执行支持仍然有限；但在分析型数据库或者部分云数据库版本里，并行查询已经是比较成熟的功能。日常开发里更常见的做法是自己在应用层把数据按某个维度拆片，开启多个连接同时执行查询，最后再合并结果。比如把一张大表按用户 ID 哈希到多个分片，每个分片单独统计，最后汇总。

5.2 大查询才适合并行，短查询反而更糟

我判断一条 SQL 是否适合并行，会先看它的基准耗时。如果单条 SQL 已经要跑几十秒甚至几分钟，而且在一个低峰时段执行，并行是值得尝试的方向；如果一条 SQL 本身只要几百毫秒，强行并行带来的线程调度、结果合并、上下文切换开销，往往会超过查询本身的时间，属于典型的负优化。

适合并行的场景通常有这几个特征：扫描的数据量大、计算逻辑简单、结果集小。比如给一张上亿行的流水表做月度聚合报表，按月份拆成多个子查询并行跑，每个子查询只扫自己负责的那几个月的数据；如果所有子查询都在扫同一张表，而且互不隔离，那最终效果很可能是磁盘 IO 被打满，查询速度不升反降。

此外，并行度不是越大越好。过高的并行度会把数据库连接池占满，影响普通在线业务。我的建议是先从 2 到 4 个并行度开始压测，观察 IO 和 CPU 是否已经打满，再决定是否继续增加。

5.3 并行不是慢 SQL 的万能药

同样一句“并行 SQL 优化”，在不少场景下其实是规避了问题本身。因为并行的前提是查询可以被拆分，如果一条 SQL 的瓶颈是索引缺失、JOIN 顺序错误、或者 WHERE 条件写成了无法命中索引的形态，并行只会放大底层的问题，让硬件消耗变得更大。正确顺序应该是：先用执行计划把 SQL 本身改写和索引调整好，确认单线程执行已经在合理范围内，如果仍然不能满足性能要求，再考虑并行方案。

我在一个实际项目里见过反面案例：报表查询因为没建联合索引，单次执行 30 秒，有人直接用并行把并发度提到 8，结果 CPU 直接飙到 100%，查询时间降到 12 秒，但数据库整体响应变慢。后来加上了正确的联合索引，单线程执行只用了 1.5 秒，连并行都不需要了。这个案例虽然简单，却很能反映问题：并行只能放大已有路径的效率，不能替代糟糕的执行计划本身。

如果已经确定某类查询确实适合并行，那还需要配套设置合理的资源限制，比如在指定会话级别控制并行度，而不是全局放开。上线前也要做充分压测，明确并行度翻倍之后，系统的其他指标是否能承受。

6. 优化上线前，怎么证明这次优化是有效的

SQL 优化最怕的就是“感觉快了”。为了不让优化结果停留在玄学层面，我每次改完都会做一组前后对比，确认优化确实生效，才允许发布到生产环境。

6.1 先做执行计划的前后对比

改写 SQL 或者调整索引之后，我会重新执行一次 EXPLAIN，并保留前后两份执行计划做对比。对比点集中在访问类型、命中索引、预估扫描行数以及 Extra 标记上。我整理了一份自己的对照表，你也可以直接参考：

但我必须强调一点：执行计划的预估 rows 只是优化器的估算值，不是实际扫描行数。它只能作为参考。更可信的验证是执行时间与资源消耗的前后对比。

6.2 用时间维度的指标做判断

我会在测试环境或者低峰期的生产环境，分别取优化前后的多次执行耗时。不能只跑一次，因为数据库第一次执行时冷缓存和热缓存的差异很大。正确做法是同一环境下跑 5 到 10 次，记录每次耗时，去掉最高和最低值后看平均水平，或者直接看 P95 分位数。

像深分页那个案例，优化前 LIMIT 500000 的查询耗时约 2.6 秒，优化后同样翻到第 50 万页，延迟关联写法耗时约 180 毫秒，性能提升了十几倍。但如果只看第一次冷缓存下的对比，可能优化前 3 秒、优化后 800 毫秒，虽然结论依然成立，但数值会更波动，不容易看出真实水平。

如果慢查询日志一直开着，优化上线后还要持续观察这条 SQL 是否还会进入慢日志。我的习惯是优化完观察一周，确认同类慢 SQL 的数量从每小时的几十条降到接近于零，才认为这次优化真正闭环了。

6.3 灰度上线，别让优化影响周边查询

SQL 优化里有一类“按了葫芦起了瓢”的情况：为 A 查询建的索引，可能让 B 查询的写入变慢；把 C 查询改成 UNION 之后，可能增加数据库连接数。所以我不建议把 SQL 变更直接全量推送，尤其在高并发核心链路上。

操作方式是先用 EXPLAIN 在预发环境验证，再在线上灰度期间关注数据库的 CPU、IOPS、活跃连接数以及锁等待时长。如果优化上线后系统负载不降反升，要能第一时间回滚变更。不要觉得优化一定总是正收益，生产环境里因为一个看似完美的索引导致写入性能剧烈下降的例子，我见过太多次。

灰度验证的关键指标包括：该 SQL 的平均耗时和 P95 耗时是否下降；数据库整体 CPU 是否下降；是否有新增的锁等待或临时表落盘；同表的写入延迟是否增加。如果这些指标都保持正常或改善，再逐步放量到全量。

六轮说下来，其实慢 SQL 优化到最后，拼的不是背多少条优化技巧，而是能不能在正确的时间用正确的工具定位到真正瓶颈。加索引、改写 SQL、调并行度，都只是围绕执行计划和数据访问模型做文章的抓手。