SQL优化实战：从慢SQL诊断到索引与深分页治理

凌晨两点，我被一通电话从床上拽了起来。线上核心库CPU打到99%，所有订单查询接口全部超时。登录跳板机，show processlist一刷，满屏都是同一条SQL在跑，单次执行就要8秒多。当时的我盯着那条SQL愣了好几秒——联表、索引、字段类型看着都没毛病，怎么就慢成这样了？

那段日子我几乎把市面上能搜到的“SQL优化最佳实践”翻了个底朝天，也在生产环境里踩了无数个或深或浅的坑。后来才慢慢意识到，所谓优化，本质上是在跟数据库的“读数据方式”做博弈。你写的每条SQL，optimizer都要绞尽脑汁猜你想干嘛，猜对了吃索引，猜错了就全表扫描，机器等着，业务卡着，用户骂着。

这篇文章我不想罗列那种“不要用select *”“记得加索引”的正确废话。我会用几个真实折腾过的案例，从执行计划、隐式转换、深分页、并行执行这些角度，讲讲一条慢SQL从发现到彻底治好的完整过程，以及那些你在文档里翻不到、只有被生产毒打之后才懂的细节。不管你是刚接手公司SQL优化任务的初级DBA，还是被慢查询日志折磨到秃头的后端开发，这篇文章应该都能帮你少走点弯路。

1. 一条“看似正常”的SQL为什么会慢得离谱

先还原一下当晚的情况。业务逻辑很简单，查某个时间段内的订单列表，再关联用户表拿昵称。SQL长这样：

sql复制SELECT
    o.order_id,
    o.amount,
    u.nickname
FROM
    t_order o
INNER JOIN t_user u ON o.user_id = u.id
WHERE
    o.pay_time >= '2024-06-01 00:00:00'
    AND o.pay_time < '2024-06-08 00:00:00'
ORDER BY
    o.pay_time DESC
LIMIT 20;

这写法挺规矩的，条件字段pay_time上有索引，关联字段user_id也有索引，分页就取20条，怎么看都不像能跑8秒的样子。可现实就是跑了8秒，还拖着整个库一起遭殃。我当时第一反应是索引失效，结果EXPLAIN一看，type是range，key也正常用了idx_pay_time，索引没毛病。

真正拖垮查询的，是在ORDER BY o.pay_time DESC LIMIT 20这一步。怎么理解呢：

• MySQL先从idx_pay_time索引找到符合条件的行，这个范围挺大的——一周的订单，2000多万行表里筛出200多万行。
• 每找到一行，就要根据主键回表查一次完整行数据。
• 回表完了，还要再拿user_id去t_user表走一遍关联，拿用户昵称。
• 拿到全部200多万行结果后，按pay_time排序，最后才取前20条返回。

也就是说，你是从200多万行的数据集里找出最大的20个，但为了这20个，前面200多万行的回表、关联、排序一次没落下。这个场景特别典型，我后来把它总结成一句话：索引帮你圈定了范围，但范围不等于答案。范围有多大，你要付出的代价就有多大。

1.1 回表不是问题，大面积回表才是问题

很多人一听到回表就紧张，觉得回表是万恶之源。其实单次回表走主键聚簇索引，速度非常快，1毫秒都用不了，纯粹按主键随机读的成本可以接受。真正的性能杀手是回表的行数。当你需要回表200万行的时候，就算每次只用1毫秒，也要2000秒的理论时间——当然InnoDB有预读、有缓冲池，实际不至于这么夸张，但性能掉到秒级甚至十秒级，太正常了。

所以优化的核心思路就一条：能不能让排序或者取值直接死在索引里，别回表？

针对那个订单查询，最简单的改动就是建一个覆盖索引：

sql复制ALTER TABLE t_order
ADD INDEX idx_pay_time_user_id (pay_time, user_id);

你可能会说，这不就是普通联合索引吗？对，就是联合索引，但加完之后效果是质变级的。因为pay_time和user_id都进了索引，查询条件走索引判断，获取user_id不需要回表，直接从索引叶子节点拿。这个就叫索引覆盖。做不做，差别非常直观：

注意，扫描行数没变，还是200多万行，但少了200多万次回表，时间直接从8秒降到2秒以内。这只是第一步，真正的质变在后面。

1.2 再快一点：延迟关联和预排序

覆盖索引把查询从8秒拉到2秒，2秒对OLTP系统来说还是太慢。接下来要对ORDER BY下手。

还记得MySQL的排序逻辑吗？拿到关联结果后需要排序，排序需要临时表。如果数据量大到超过内存排序阈值，还要在磁盘上用文件排序（filesort），这又是一次灾难。所以我当时的做法是：先单独从t_order表查出要的20个订单ID，再拿着这20个ID去关联用户表和订单表拿完整数据。

sql复制SELECT o.order_id, o.amount, u.nickname
FROM (
    SELECT order_id
    FROM t_order
    WHERE pay_time >= '2024-06-01 00:00:00'
      AND pay_time < '2024-06-08 00:00:00'
    ORDER BY pay_time DESC
    LIMIT 20
) tmp
JOIN t_order o ON tmp.order_id = o.order_id
JOIN t_user u ON o.user_id = u.id;

思路很直白，先让订单表自己把索引利用到极致——从联合索引排序，能取20个就只取20个。子查询里不是select *，是select order_id，所以整个排序过程可能都发生在索引里。等入围的那20个order_id确定后，再回表去拿完整数据，关联用户表只需要关联20次。这个回表次数从200万次砍到20次，不卡都不可能。

实测下来，这条SQL稳定在80毫秒以内。

1.3 这个案例教给我什么

现在回头看，这条SQL的优化路径是一条很典型的三级跳：

1. 先让查询别回表——用覆盖索引把回表省掉，代价从8秒降到2秒。
2. 再让排序别排那么多——用延迟关联把排序数据集从200万砍到20，代价从2秒降到80毫秒。
3. 最后让驱动顺序更合理——小表驱动大表，先把数据规模压下去，后面的事都好办。

说实话，这80毫秒还不是理论的终点，因为在MySQL 8.0里还能用窗口函数、还能进一步改造表结构，但从投入产出比看，已经足够了。SQL优化最忌讳一件事——为了极致而极致，把简单查询改成天书一样的复杂语句，维护成本上去了不说，optimizer还容易优化出反效果。优化的目的是让业务跑得顺畅，不是炫技。

2. 索引失效机制：那些让优化器“装瞎”的写法

第一条SQL折腾完，我本以为自己的SQL功力已经大涨，结果没过两周，同样的深夜，另一条查询又把我按在地上摩擦了。这次的SQL更短：

sql复制SELECT *
FROM t_payment
WHERE order_no = 202406150001234;

order_no字段上明明建了唯一索引，EXPLAIN看过去type却是ALL，rows显示扫描了600多万行。我当时都快怀疑人生了，索引就在那儿，InnoDB凭什么视而不见？

后来小心翼翼试了一下order_no = '202406150001234'，把条件右边的数字改成字符串，结果type从ALL变成const，执行计划瞬间就正常了。问题出在哪？字段类型是varchar，查询条件却传了数字。MySQL的优化器在比较时会做类型转换，把varchar字段转成数字去比，但一旦在索引列上做了函数操作或隐式转换，索引就失效了。这个机制可以用一个很简单的类比理解：你把一整本字典的页码都写成了“一百二十三”，然后有人让你按“第一百二十三页”去找，你只能从第一页翻起，因为字典没法按中文快速定位。隐式转换的本质，就是让数据库对索引列做了“处理”，原有的索引排序结构自然就帮不上忙了。

2.1 不止是字段类型，函数和字符集也会让索引失效

把订单号的隐式转换搞定后，我又整理了一组自己踩过或者说同事踩过的高频“杀索引”操作。每一条都曾经在某个深夜让某个倒霉蛋爬起来看执行计划：

• 对索引列使用函数：比如WHERE DATE(pay_time) = '2024-06-11'。这不是说函数有问题，而是DATE()套在列上，MySQL只能全表扫描。应该改成范围查询pay_time >= '2024-06-11 00:00:00' AND pay_time < '2024-06-12 00:00:00'。
• 隐式字符集转换：两张表关联时，如果字段一侧是utf8mb4，另一侧是utf8mb3旧版本，MySQL会在关联时偷偷做字符集转换，导致一侧索引失效。这个极难发现，因为EXPLAIN都不一定会报警告。排查方法是对两个字段都加上CONVERT显式处理，看执行计划是否能从ALL变成ref。
• 前导模糊匹配：LIKE '%关键字%'。前导通配符让索引树无处下手。如果业务确实需要包含查询，要么上全文检索，要么考虑ES，硬顶着索引优化就是在做无用功。
• 对索引列做计算：WHERE price * 0.8 > 100，同样会让索引失效，要把计算挪到等号右侧：WHERE price > 100 / 0.8。
• OR连接非索引列：WHERE id = 100 OR status = 1，如果status没有索引，优化器为了合并结果只能舍弃id索引走全表。解决办法是拆成两条SQL用UNION连接，或者给status也加上索引。

这五种情况，几乎涵盖了新手甚至部分老手写SQL时会犯的典型错误。每次遇到慢SQL，我都会先干一件事：看EXPLAIN结果的type字段，只要不是const、eq_ref、ref、range，而是ALL（全表扫描），就要警惕是不是有上面的情况在作怪。

2.2 一个特殊的坑：区分度不够，索引也会被弃用

还有一类更隐蔽的情况必须单独拎出来说。有时候明明没写错任何东西，字段类型、字符集、函数都对，索引还是不被使用。

比如性别字段，你建了个索引，但一张表里90%是男性，10%是女性。当你查性别为“男”的那部分数据时，优化器一算，走索引需要回表90%的数据，比直接全表扫描还慢，干脆弃用索引。

这是优化器基于成本估算做出的理性决策，不是Bug。所以索引不是建的越多越好，字段区分度太差的话，建了也是白建。性别、状态、是否删除这类只有两个取值或少量取值的字段，除非是联合索引的尾部字段，否则尽量不要单独建索引。

3. 深分页：LIMIT后面藏着的性能黑洞

如果你对“SQL优化最佳实践”有过一些了解，肯定见过有人提醒：LIMIT深分页会让查询越来越慢。但很多人知其然不知其所以然。我见过一个报表系统，翻到第10000页的时候，接口5秒都出不来，运维把慢查询日志贴给我，SQL就长这样：

sql复制SELECT *
FROM t_operation_log
ORDER BY create_time DESC
LIMIT 300000, 20;

刚看到这条SQL，我的表情是痛苦的。三个大坑凑齐了：select *、深分页、排序字段还不在覆盖索引里。

这个SQL慢在哪呢？LIMIT 300000, 20的意思是，MySQL要从排序后的结果集里跳过300000行，取第300001到第300020行。排序它躲不掉，跳过它躲不掉，而且更坑的是——前面那30万行都要回表取完整数据，即便你只需要第300001到300020行的数据。就像你从一本厚书里找第300页的内容，结果图书馆管理员为了帮你找到第300页，把前299页都给你复印了一遍，最后才把第300页递给你。

3.1 优化思路：把“翻页”变成“游标”

传统的深分页优化方案，最常用的就是记录上一页最后一条的排序值，用游标来做下一页查询，而不是继续翻页码。比如第一页查完后，记录最后一条数据的create_time，假设是2024-06-01 12:00:00，那第二页的SQL就改成：

sql复制SELECT *
FROM t_operation_log
WHERE create_time < '2024-06-01 12:00:00'
ORDER BY create_time DESC
LIMIT 20;

这样MySQL就不需要再跳到第30万行去数了，它会直接走索引找到日期小于2024-06-01 12:00:00的第一条，然后顺序往下取20条，扫描行数也就是20行左右。这是质的飞跃。代价是业务接口需要从页码翻页改成加载更多或滚动分页。

如果确实需要保留页码跳转功能，还有一招——延迟关联 + 覆盖索引：

sql复制SELECT t.*
FROM t_operation_log t
INNER JOIN (
    SELECT id
    FROM t_operation_log
    ORDER BY create_time DESC
    LIMIT 300000, 20
) tmp ON t.id = tmp.id;

子查询里只查id和create_time，这两个字段正好是联合索引（或覆盖索引）里的，那么排序过程不需要访问数据行，直接索引搞定；取到那一页的20个ID后，再回原表取全量数据，只回表20次。之前那种“前30万行全部回表”的浪费就彻底消失了。

3.2 实测数据对比

为了把收益讲得直白点，我在一个600万行数据的测试表上跑了三种写法，结果如下：

我的建议是：如果你是做ToC接口，能改造产品用游标分页就尽量用游标分页，响应速度是另外几种方案比不了的；如果业务实在要页码跳转，那就用延迟关联把回表数量降下来。LIMIT 300000, 20这种赤裸裸的写法，唯一的归宿就是彻底重写。

4. 并行SQL优化：不是所有场景都适合并行

聊完深分页，再聊点被捧上神坛的概念——并行SQL。相关热词里频繁出现“并行sql优化”，但我实际观察下来，不少团队对并行的理解仅停留在“把一条慢SQL拆成多条快SQL，一起执行再合并结果”。这个思路理论上没错，落地时踩的坑却一个比一个深。

先说说MySQL 8.0自带的一个特性：并行读。在EXPLAIN或者开启innodb_parallel_read_threads参数后，部分涉及InnoDB大表扫描的查询能够利用并行线程读取数据页。这个参数不是万能的，它只对全表扫描或大范围扫描有加速效果，对于那种走主键点查、走二级索引范围扫描的查询，提升基本可以忽略。原因也好理解，InnoDB的B+树本身是按页组织的，只有扫描的页足够多、读取的IO足够密集，拆成多个线程去并行读才有收益，否则线程调度开销反而会拖慢整体速度。我在测试环境里用一张几千万行的日志表跑过COUNT(*)全表统计，把innodb_parallel_read_threads从默认的4调到8，耗时降了差不多一半；但对一个走索引的订单点查启用并行，几乎没有任何变化。

而在真正的业务并行上，我见过一类错误的用法——把一个大查询拆成十几个子查询丢到线程池里跑，最后合并结果。听起来很硬核，实际上有一堆麻烦：

• 每个子查询可能各自扫了一大段数据，总体扫描量反而比单条SQL更大。
• 线程池资源被查询任务占满，正常的小事务排队等待，整体吞吐量下降。
• 多个并发子查询如果同时落在同一张表上，IO争抢严重，可能比串行跑还慢。
• 事务隔离级别下有可见性差异，如果查询过程中有数据变更，结果一致性很难保证。

所以我现在的观点趋于保守：并行SQL优化要小步快跑，先分析慢SQL属于什么类型。如果单条SQL慢是因为排序、关联、深分页这类逻辑问题，优先改造SQL本身，比如前面说的覆盖索引、延迟关联。只有当你确认SQL已经写得足够好、瓶颈确实卡在大规模数据扫描上、数据本身的分区条件又特别清晰的时候，才值得考虑并行拆分。

一个适合拆并行的经典场景是统计类报表，比如要算一个月所有门店的销售额汇总。按门店维度拆，一个店一个子查询，天然不产生中间结果重叠，跑完合并就行。还有一个是按时间分片，要批量清洗一张十年的流水表，按年份拆成10个任务并发跑，每个任务独立更新自己时间段的数据，互不干扰。但注意，这些场景本质上是业务逻辑层面的数据分片并行，和数据库内部的并行执行不是一回事，但胜在可控、可观测、出错了容易回滚。

要判断一条SQL能不能拆，可以问自己三个问题：

1. 拆出来的子任务会不会扫描同一批数据？如果会，说明做了重复劳动。
2. 子任务之间有没有共享的可变状态？如果有，并发写就会出乱子。
3. 单条SQL是不是已经足够简单了？如果一条SQL还带着复杂的join和排序就硬拆，结果合并时的排序会让人欲哭无泪。

5. 从被动救火到主动防御：慢SQL治理的日常功课

如果每次都等到线上挂了才去抓慢SQL，那就永远处于被动救火的状态。真正成熟的团队会把SQL优化前置，让慢SQL在压测阶段或上线之前就暴露出来。

5.1 慢查询日志和EXPLAIN的正确用法

刚开始查慢SQL的时候，我习惯一条一条看slow_query_log，然后跑去生产库手动跑一遍EXPLAIN。后来发现这种做法既低效又危险——生产库跑慢查询sql，可能没把你想要的数据跑出来，反而先把数据库负载干上去了。更稳妥的方式是在测试环境或者从库上执行，先获取执行计划，再小流量验证耗时。

启用慢查询日志的配置项，我一般这样设置：

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

long_query_time = 1意味着超过1秒的查询会被记录。对于核心交易系统，我会建议调到0.5秒甚至0.2秒；分析型报表库则可以放宽到2秒以上，否则日志量太大会影响数据库性能。

日志拿到手后，EXPLAIN的阅读顺序也很重要。大多数人习惯先看key有没有值，这其实不够。我自己的习惯是先看type：

• system和const是最高境界，说明这行数据最多读一行就出来了。
• eq_ref出现在主键或唯一索引关联里，是联表查询中最理想的状态。
• ref表示用到了非唯一索引的等值匹配，也OK。
• range表示索引范围扫描，有索引支持，但要关心扫描范围大小。
• index比全表好一点，但也别高兴太早，这通常是索引全扫描，数据量照样吓人。
• ALL就是全表扫描，属于重点打击对象。

看完type再看rows列。很多新手会忽略rows，但它是预估扫描行数，直接反映这条SQL要碰多少行数据。如果rows是500万，哪怕key看起来用了索引，也要琢磨能不能减少扫描范围。最后看Extra列里有没有出现Using filesort和Using temporary，这两个词一出现，说明排序或去重操作没法在索引上直接完成，很可能需要优化SQL或者加合适的索引。

5.2 一个通用排查模板

这里总结一个适用性很高的慢SQL排查模板，我自己每次处理线上慢SQL基本都按这个流程走：

1. 拿到慢SQL，先肉眼检查有没有显眼的错误：是不是select *？是不是深分页？条件列上有没有函数？关联字段类型是否一致？
2. 在测试库跑EXPLAIN，看type、rows、Extra三个关键字段。
3. 根据执行计划判断瓶颈方向：rows大就加索引或改查询范围，Using filesort就看看能不能用索引排序，Using temporary就检查group by或distinct的字段。
4. 改写SQL，优先选择覆盖索引、延迟关联、游标分页这些“小改动大收益”的方案。
5. 回归测试后，再跑一遍EXPLAIN和实际耗时对比，确认优化有效。
6. 把优化后的SQL沉淀到团队文档里，方便下次其他人参考。

这套流程看似简单，但当你能坚持执行，就会逐渐形成一种对SQL语句的直觉：看到一条查询，就能大概猜出它的执行计划和性能瓶颈。这种直觉，不是靠看文档看出来的，是靠一条一条分析慢SQL喂出来的。

5.3 索引设计的老生常谈，我们换个方式讲

说到SQL优化，避不开索引设计。但我不想再重复那些“为高频查询建索引”“索引列不要参与运算”之类的老话。我想分享一个更偏实战的判断维度：单表索引数量别搞太多。

我接手过一个极端case，一张订单扩展表上建了二十几个索引，几乎每个查询条件组合都能命中一个索引。听着很爽吧？实际上写入性能惨不忍睹，每次insert一行数据，InnoDB要维护二十几个B+树索引节点，插入耗时直接从1毫秒涨到9毫秒。这个代价在高并发写入场景下是致命的。

所以我现在给团队的建议是，控制单表单列索引数量，尽量让高频的组合查询走联合索引。比如用户中心的查询，既有按创建时间排序的，又有按状态过滤的，那可以考虑建一个(status, create_time)联合索引，比单独建两个单列索引覆盖的场景更广，写入压力也更小。

关于联合索引有一个容易忽略的细节：最左前缀原则。联合索引(a, b, c)，查询条件要包含a才能走索引，只有b和c时索引帮不上忙。所以设计联合索引时，一定要把最高频的查询字段放在最左边。建索引前先在脑海里跑一遍当前业务的top查询，看看能不能用索引覆盖它们。不要为了以后可能出现的需求提前建索引，索引这东西，宁可先不加，等真出现慢查询了分析完再补都来得及。

5.4 业务层兜底：缓存和限流不冲突

做SQL优化的人容易陷入一个误区：所有问题都应该靠数据库解决。实际上，当一条SQL到了怎么优化都压不进某个阈值时，业务层兜底是完全合理的选择。

我在订单详情场景下用过Redis缓存，key设计成订单维度，缓存查询结果15分钟，热点订单的查询压力直接打到缓存上，数据库的读负载瞬间降下来。对于某些报表聚合结果，只要不是要求绝对实时的数据，其实也可以放到缓存或异步计算中，定期刷新结果集。这样SQL优化的目标和压力都变小了——你只需要保证缓存miss时那一小部分请求能在合理时间内返回即可。

当然，也别把缓存当作万能药。缓存雪崩、缓存击穿、缓存一致性这些问题都会随之而来。但我的经验是：当数据库层面能做到80分，想要继续往95分走，性价比会变得很差；这时候把一部分读请求分流到缓存，反而能让整体系统稳定性更高。SQL优化和缓存设计不是互斥的关系，是同一个目标下的协同工具。

6. 优化完还没完：如何让优化效果不被下一次上线打回原形

最后想聊聊SQL优化里一个很少有人提、但非常重要的话题——优化成果的维护。

很多团队解决慢SQL的方式是靠“救火队长”式的高手，他看一眼慢日志，啪一下加个索引，啪一下改条SQL，性能上来了，问题结束了。但三个月后，某个开发随手加了个查询条件，或者某张表的数据量翻了一倍，慢SQL又回来了，而且可能比之前还严重。这时候，之前那位高手的经验没有被沉淀，团队其他人也不清楚当初为什么那样改，又得从头排查。

所以我强烈建议：每次做SQL优化，都把下面这些信息记录到团队的Wiki里：

• 原始SQL和执行计划（包括type、rows、Extra）
• 优化后的SQL和执行计划
• 优化前后的性能数据对比
• 数据的规模变化趋势（表里多少行，查询范围多大）
• 优化的核心思路（用一两句话说清楚为什么这么做）
• 后续需要关注的边界条件（例如数据量再翻几倍时可能需要重新评估）

有了这样一份记录，下一次出现类似慢SQL，排障的起点就不会是零，而是站在上一次的结论之上。几个迭代下来，团队对数据库性能问题和索引设计的理解会提升很快，需要你的“深夜救火”次数也会越来越少。

另外，不少团队会专门设一个巡检任务，用performance_schema定期去统计高频SQL的快照，对比同一SQL在不同时间窗口下的平均延迟。这个做法非常有效——数据量增长不会突然让某条SQL从10毫秒变成10秒，它通常是渐变的，但如果巡检脚本能发现它从10毫秒慢慢涨到200毫秒、再涨到1秒，那你就能在它变成事故之前把它处理掉。

我个人在实际运维中还有一个很小的习惯：每次调整索引或者改完SQL后，会顺手在测试环境跑一轮常用业务的回归，而且不只跑功能，也跑那些涉及大表查询的case。因为加索引虽然对查询是优化，但有可能会影响写入的锁行为或者改变优化器在某些语句上的执行路径，这些影响有时候不会立即暴露。花半个小时做一轮回归，比第二天被业务方投诉查询结果变慢划算得多。

SQL优化的路走到后面，其实拼的不是你知道多少条技巧，而是你对数据在磁盘、内存、索引、执行引擎之间是怎么流动的，有没有一个清晰的模型。你越是理解那些结构，越明白一条SQL有资格快，不只因为它语法漂亮、索引齐全，而是因为整个执行链路里不存在“浪费的步骤”。每次优化，本质上都是一次对浪费的剔除——删掉多余的回表，删掉跳过的30万行，删掉让索引失效的隐式转换。删着删着，你会发现自己写的SQL越来越贴合数据库的脾气，而线上投诉也会越来越少。