慢SQL优化实战：从日志采集到索引设计，一套可复用的排查方法论

搞业务系统的同学应该都有过这种经历：线上某个页面突然变慢了，用户截图反馈过来，配上一句“你们系统卡死了”，你赶紧登录服务器去查，第一反应就是打开数据库慢查询日志看一眼。十个案例里至少有七个，问题最终都落在SQL上。

SQL耗时这件事，平时没人觉得它重要，但一旦线上出故障，它就是第一个背锅的。尤其是业务系统跑了一两年之后，数据量上来了，索引没跟上，接口里塞了几个隐式类型转换或者深分页查询，性能立刻见底。我自己这些年处理慢SQL优化，慢慢形成一个观点：慢查询本质上不是数据库的问题，是数据库在替业务代码的坏习惯买单。所以这篇文章不打算讲一堆空洞的“要建索引”之类的废话，而是把我实际处理过的问题、排查路径和优化手段都摊开来讲，从怎么统计、怎么分析，到怎么对症下药，形成一套可以复用的方法。

这套方法不只适合DBA，后端开发、系统架构师、甚至刚入行的初级工程师都应该看看。很多时候SQL就是业务代码的一部分，能在代码评审阶段发现慢查询隐患，比等线上慢查询日志报警再救火，成本要低得多。

1. 先从哪一类慢查询开始治理？先确认日志开关和采集方式

1.1 业务系统里的慢SQL到底藏在哪

在业务系统里，慢SQL不是一个“有没有”的问题，而是一个“什么时候爆发”的问题。常见的几个重灾区我列一下：报表统计类接口、列表分页接口、订单状态流转时的查询、后台管理端的模糊搜索、凌晨跑批任务里的批量更新。这些场景的共同特点是，表面看代码没改过，但表里的数据量一直在涨，等涨到某个临界值，SQL执行计划就变了——之前走索引，现在开始全表扫描，耗时从几十毫秒直接跳到几秒。

还有一个经常被忽视的地方：同一个SQL在测试环境没事，一到生产环境就慢。原因很简单，测试环境的数据量是生产环境的百分之一，优化器看一眼数据分布发现全表扫也很快，自然不会选索引。而你拿测试环境的数据去分析执行计划，什么都看不出来。所以说，治理慢SQL的第一件事，是让生产环境的慢查询日志长期保持打开状态，并且把采集和监控搭建好，而不是等出故障了再临时开。

1.2 慢查询日志怎么打开，阈值怎么设置才不误伤

以MySQL为例，慢查询日志默认是关闭的，线上一般会通过如下配置打开：

conf复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 0
min_examined_row_limit = 100

这里面最关键的一个参数就是 long_query_time。我见过很多团队把它设成10秒，美其名曰“我只关心特别慢的查询”，实际上这是个大坑——因为一条SQL从追责的角度看，超过1秒就已经会让用户感知到卡顿，等10秒再去排查，该影响的用户早就被影响了；而且等到日志里出现的都是10秒级的灾难时，你根本不知道问题是什么时候开始恶化的。我一般建议设置为1秒，如果你们系统整体性能特别好，可以进一步调到0.5秒，对于绝大多数业务系统来说，1秒是合适的起点。

另外几个参数也有讲究。log_queries_not_using_indexes 这个选项如果打开，会把所有没走索引的查询都记下来，哪怕只执行了0.001秒，日志量会非常巨大，容易产生磁盘写入瓶颈，所以一般不建议全局开着，只在特定排查窗口临时开启。min_examined_row_limit 表示扫描行数超过多少才记录，可以用来过滤掉一些扫描行数极少的小查询，避免日志里充斥着没意义的记录。

如果你用的是云数据库，控制台一般自带慢查询统计功能，不需要自己采集；如果是自建库，建议把慢日志输出到独立磁盘，并且做一个简单的日志切割，不然日志文件增长速度会超出你想象。我维护的一个系统疯狂时期慢日志一天能涨5GB，如果不做切割和归档，很容易把数据库磁盘撑爆。

2. 统计慢查询不能只靠肉眼，盘点TOP慢SQL的几种方式

2.1 先用笨办法从日志里翻出“惯犯”

慢查询日志打开之后，会积累大量记录。一条典型的MySQL慢日志长这样：

log复制# Time: 2024-11-17T10:23:45.123456Z
# User@Host: app_user[app_user] @  [10.10.10.23]
# Query_time: 2.345678  Lock_time: 0.000123 Rows_sent: 20  Rows_examined: 120000
SET timestamp=1731839025;
SELECT order_id, order_status, total_amount
FROM orders
WHERE user_id = 1024
ORDER BY created_at DESC
LIMIT 20 OFFSET 100000;

看到这样的日志，千万不要只看 Query_time，还要重点看 Rows_examined 和 Rows_sent 的比值。这条SQL返回了20行，却扫描了12万行，扫描行数和返回行数差了6000倍，妥妥的“用大炮打蚊子”。行扫描数才是衡量SQL是否健康的重要指标，因为它直接反映查询走了多少无用功。

要统计哪些SQL出现频率最高、累计耗时最长，MySQL自带的 mysqldumpslow 工具就够了：

bash复制mysqldumpslow -s at -t 20 /var/log/mysql/slow.log

这个命令会按照平均查询时间排序，输出前20条慢SQL的汇总。它能自动把数字和字符串变量归一化，把同结构的SQL归并到一起，比如上面这条SQL和 user_id=2048 的同类SQL会被汇总成一条统计。实际排查时你会发现，造成问题的往往不是某一条SQL，而是某几类SQL反复出现，它们才是需要优先处理的“惯犯”。

2.2 引入专业工具，把慢查询盘成一张体检报告

mysqldumpslow 能解决的问题是“找出哪些SQL慢”，但如果你想进一步知道“慢在哪些阶段、锁等待占了多少时间、扫描了多少行”，它会显得力不从心。这时候我会用 Percona Toolkit 里的 pt-query-digest，它对日志的解析粒度更细，输出结果也更像一份体检报告。

bash复制pt-query-digest /var/log/mysql/slow.log > digest_report.html

生成的报告里有几个关键模块。最上面的“Profile”部分会列出所有慢查询的排名，每一行都能看到总执行时间、执行次数、平均耗时、平均返回行数、平均扫描行数。第二个重点是“Tables”部分，它会告诉你哪些表参与了慢SQL，以及这些表的访问模式。第三个就是各条SQL的详细剖析，包括是否走了索引、是否有临时表、是否有filesort等。

用这个工具分析几次之后，你会形成一套自己的判断标准。我个人看报告的习惯是这样的：先看执行次数最多的SQL，因为高频率小延迟的累积效应往往比单次大延迟更可怕；再看扫描行数特别高的SQL，因为它们是索引失效的典型信号；最后看有没有 Rows_examined / Rows_sent 比例超过1000的SQL，这类SQL即使响应时间没超过阈值，数据量增长以后也一定会出问题。

如果数据库版本支持，还可以直接查MySQL内置的性能库，比如 performance_schema 或 sys 库：

sql复制SELECT * FROM sys.statement_analysis ORDER BY total_latency DESC LIMIT 20;

这条查询会直接拉出当前实例所有SQL的延迟统计，不需要依赖慢日志文件，排查生产环境更及时。PostgreSQL里有类似的 pg_stat_statements，Oracle里有AWR报告，原理大同小异：先把数据库执行过的SQL统计起来，再用工具去排序、过滤、定位问题。

3. 分析慢SQL前，先搞懂为什么慢：执行计划必须会看

3.1 用EXPLAIN给SQL做一次“体检”

找到慢SQL之后，第一步不是改代码，而是看它的执行计划。MySQL里就是在SQL前面加 EXPLAIN 关键词：

sql复制EXPLAIN SELECT order_id, order_status, total_amount
FROM orders
WHERE user_id = 1024
ORDER BY created_at DESC
LIMIT 20 OFFSET 100000;

执行计划里字段很多，但实际排查时重点关注几个就够。我这里按照重要程度说：

type 这个字段代表访问表的方式，从好到差依次是 system、const、eq_ref、ref、range、index、ALL。很多初学者一看到 ALL 就慌了，其实不用慌，要结合数据量看。一张只有几百行的配置表走 ALL 完全没问题，但一张上千万行的核心业务表如果出现 ALL，那就是红色警报，说明优化器放弃了索引，选择把整张表翻一遍。

key 表示实际用到的索引，如果显示为NULL，说明没走索引。rows 是估算的需要扫描的行数，这个数字和慢日志里的 Rows_examined 相差越大，执行计划的估算越不准。Extra 里经常会出现一些“题眼”：Using filesort 代表MySQL需要额外的排序操作，通常是因为排序字段没被索引覆盖；Using temporary 代表查询使用了临时表，常见于 DISTINCT、GROUP BY、UNION 子句；Using index 反而是好消息，代表查询在索引里就能拿到全部需要的字段，不需要回表。

我一般会根据这些字段快速判断优化方向：如果 rows 很大，优先考虑加索引或改写过滤条件；如果出现 Using filesort，就要想想排序字段能不能合并到索引里去；如果 type 是 ALL 但查询频率不高，可以先观察，不必一上来就改。

3.2 索引到底是“加得越多越好”还是“够用就行”

很多新手对索引有一种误解，以为索引是万灵药，只要查询慢就加索引，一张表恨不得建二十个索引。这种做法其实埋了更大的雷：索引不是免费的，每次插入、更新、删除都要额外维护索引结构，索引太多会拖慢写入性能，还占用大量磁盘空间。

我理解索引的本质是一种“有序的冗余存储”，它的核心作用是把原来需要线性扫描的操作，变成近似二分查找的对数级操作。但正因为索引是冗余的，就不能无限建。准确的说法应该是“够用就行”——给你的核心查询路径建立合适的联合索引，让过滤条件、排序条件尽量被同一个索引覆盖。

举个典型例子，订单表经常有这样一个查询：

sql复制SELECT order_id, total_amount, status
FROM orders
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 20;

这种场景下，单纯给 user_id 建一个普通索引不够好，因为MySQL在索引里找到匹配的订单后，还要对结果按 created_at 做一次排序。更优的方案是建联合索引 (user_id, created_at)，这样索引本身就是按照用户和下单时间双重排序的，查询时顺序读取就能直接返回结果，连排序都省了。

联合索引设计要遵循最左前缀原则，查询条件必须从联合索引的第一列开始匹配，索引才能生效。举例来说，索引 (user_id, status, created_at) 能支持 WHERE user_id=1 AND status='PAID' ORDER BY created_at DESC，但不支持只按 status 或者只按 created_at 作为第一列的查询。所以联合索引列的顺序很重要，我的经验是：等值查询的列放前面，范围查询和排序的列放后面。这样做是因为等值列可以让索引匹配更精确，范围列则天然会中断后续列的排序能力。

3.3 看一眼就知道索引失效的几种情况

建了索引不等于就能用上，索引失效的坑我在生产环境里踩过太多次。最典型的几种，我直接罗列出来：

第一种是 在索引列上做函数运算，这个应该算是所有失效场景里最容易踩的。比如 WHERE DATE(created_at) = '2024-11-17'，你在日期列上套了个 DATE() 函数，索引就失效了。原因是MySQL需要先对每一行的 created_at 算出日期值，才能和字符串比较，这个计算过程让索引的有序性完全没有意义。正确的改写方式是：

sql复制WHERE created_at >= '2024-11-17 00:00:00'
  AND created_at < '2024-11-18 00:00:00'

第二种是 隐式类型转换，比如字段是字符串类型，查询条件却写成了数字：

sql复制-- phone 字段在表里是 varchar，这里却传入了数字
SELECT * FROM user_phone WHERE phone = 13800138000;

MySQL会先把字段转换成数字再比较，导致索引列的原始值被“加工”了一遍，索引自然就失效了。正确做法是让查询参数的类型和字段类型保持一致，传字符串进去：

sql复制SELECT * FROM user_phone WHERE phone = '13800138000';

第三种是 LIKE 以通配符开头，比如 WHERE name LIKE '%张%'，因为通配符在最前面，优化器无法利用索引的有序性进行前缀匹配，只能一个个扫。如果业务确实需要中间模糊匹配，要么考虑全文索引，要么在早期设计时预留一个倒排字段。

4. SQL改写不是玄学，核心思路是“让数据库少干活”

4.1 大分页优化：从深翻页到延迟联接

分页查询的慢是最容易感知的，用户点下一页，越到后面越慢，最后可能直接超时。原因不难理解：MySQL里的 LIMIT 100000, 20 并不是“跳过前面10万行，然后只查20行”，而是“扫描前10万行并全部丢弃，再读取接下来的20行”。这个偏移量越大，数据库做的无用功就越多。

一个经典的优化思路是用 延迟联接。先只查主键，然后再关联回原表取完整的行数据：

sql复制-- 优化前：直接翻页到第5000页
SELECT * FROM orders
WHERE user_id = 1024
ORDER BY created_at DESC
LIMIT 20 OFFSET 100000;

-- 优化后：先在二级索引上取主键，再回表
SELECT o.*
FROM orders o
INNER JOIN (
    SELECT id
    FROM orders
    WHERE user_id = 1024
    ORDER BY created_at DESC
    LIMIT 20 OFFSET 100000
) t ON o.id = t.id
ORDER BY o.created_at DESC;

这样改动的好处是，内层子查询可以完全在联合索引 (user_id, created_at, id) 上完成，扫描的行数虽然还是很多，但每行都是紧凑的索引记录，IO量小很多；外层再通过主键精准取20条完整数据，回表次数被限制在很小的范围里。用这个思路优化过一条千万级订单表的查询，耗时从1.8秒降到了不到100毫秒，效果非常直观。

如果业务上翻页场景是“加载更多”而不是“点击页码”，还可以用游标方式翻页：前端把当前页最后一条记录的 created_at 或ID传回来，SQL改成 WHERE created_at < ? ORDER BY created_at DESC LIMIT 20，查询位置直接跳到目标区域，完全不依赖OFFSET。许多资讯类App的下拉加载就是这么做的，体验好，数据库压力也小。

4.2 SELECT只看需要的列，别把“SELECT星”当习惯

这个点听起来很小，但实际影响比很多人想的大。SELECT * 在InnoDB里会让优化器失去使用覆盖索引的机会。举个例子，表上有联合索引 (user_id, created_at)，查询要的只是 total_amount，如果写成 SELECT total_amount，优化器可以直接从二级索引里取数，不需要回主键索引查整行数据，速度自然快；但如果你写 SELECT *，二级索引里没有其他字段，还得到主键索引里把完整的行数据捞回来，这属于“白跑一趟”。

另一方面，返回不必要的字段还会增加网络传输的负担。一张表如果有三四十个字段，里面还带个 TEXT 类型的备注字段，你明明只需要列表页的订单号和状态，却把几千字节的备注内容也查出来了。接口变慢的原因不一定是查询慢，有可能纯粹是“传了一大堆没用的数据”。很多团队对SQL做代码评审时，第一条规则就应该是不允许写 SELECT *，除非你真有明确理由需要所有字段。

4.3 子查询和JOIN别盲目改写，优化器比你想象中聪明

网上经常会看到“子查询慢，要改成JOIN”之类的说法，实际上这种结论放到不同数据库版本里根本不成立。MySQL 5.6以后，优化器会对子查询做自动重写，把许多可以上拉的子查询改成半连接（semi-join）执行，性能不一定比手写JOIN差。反过来，有些场景里把JOIN改成EXISTS反而更好，因为EXISTS可以提前终止内层循环，不需要找到所有匹配行。

所以我的建议是，不要死记“子查询必须改JOIN”这种旧时代的经验，正确的姿势是先看执行计划，再看SQL耗时。如果优化器已经给出了不错的执行计划，哪怕写法看起来不优雅，只要性能达标，就不用动它。真正需要手动改写的，通常是你发现优化器的选择有问题，比如驱动表选错了、内层查询被反复执行、出现了临时表等，这时候才值得人工介入。

4.4 用OR连接条件时要小心，UNION不一定更好但也不一定更差

OR 条件在索引使用上确实是个坑。比如 WHERE user_id = 1024 OR order_status = 'PAID'，如果 user_id 和 order_status 分别有独立索引，优化器可能采用索引合并（index merge）策略，也有可能放弃索引直接全表扫描，要看数据分布和优化器的成本估算来决定。

遇到这种情况，我一般会先用 EXPLAIN 看执行计划。如果走了 ALL，才考虑改写。改写方式是把一个含OR的查询拆成两个独立查询再用 UNION ALL 合并：

sql复制SELECT * FROM orders WHERE user_id = 1024
UNION ALL
SELECT * FROM orders WHERE user_id != 1024 AND order_status = 'PAID';

注意我在这里加了 user_id != 1024 做去重条件，否则两个查询结果集里可能出现重复数据。这里还要强调一下，能不用 UNION 就不用 UNION，因为 UNION 自带去重操作，会产生临时表和排序开销；只有 UNION ALL 是直接把结果拼在一起，成本低很多。

5. SQL已经改无可改了？再往上走就是架构层的优化

5.1 加一层缓存不是万能药，但要分场景用对

SQL优化做到位之后，如果读请求量还是非常大，单靠数据库已经很难顶住了。这时候最常见的方案就是引入缓存。很多技术文章喜欢笼统地说“用Redis优化查询”，但真到了业务系统里，缓存方案要分场景设计，不能简单粗暴地“查完塞Redis，下次先读Redis”。

比如热点数据的缓存适合放在Redis里，像用户信息、商品基础信息、配置字典，这类数据更新频率低、读取频率高，用缓存可以大幅降低数据库压力。我遇到过的最典型的“成功案例”是一个商品详情列表接口，数据库查询从单次几百毫秒，到热点商品被访问时数据库基本没压力，靠的就是对商品基础信息做了一级缓存。

但有些数据不适合缓存，典型的就是“与当前用户强相关且实时性要求高”的查询，比如个人订单状态。如果缓存了，用户刚下单就刷新页面看到状态没变，一定会认为是系统出bug了。这类数据可以考虑用“查数据库 + 过期时间极短”或者直接查库，保证数据一致性优先。另外，缓存更新的一致性问题是很大的隐性成本，先更新数据库还是先删缓存、消息队列通知如何兜底，每一种方案都有自己的坑，需要结合业务接受程度去权衡。

5.2 用汇总表/预聚合替代实时精确计算

很多慢查询不是“查得慢”，而是“算得重”。比如统计一个用户在某个时间段内的订单总额、统计某个商品的月销量，如果每次都实时对明细表做 SUM 和 GROUP BY，数据量一大就会很吃力。

高并发场景下，更稳妥的思路是使用 汇总表 或者 累加字段，在订单落库的同时更新一个统计表字段。举例来说，一个商家后台需要显示“今日订单数”“今日销售额”，如果每次打开后台都从订单明细表里实时分组汇总，压力会非常大；但如果订单插入时同步更新一张商家每日统计表，后台查询只需要对统计表做一次简单查询，速度自然快。代价是你会多一份逻辑，需要处理并发更新、状态回滚等边界条件。

这种方案的核心取舍在于：把“查询时的计算”前置成“写入时的计算”，用写入的多余开销换查询的高性能。对C端用户来说，下单这个动作多花几毫秒问题不大，但商家后台的查询如果每次两三秒，体验上就很难接受。所以，凡是报表类、统计类、看板类需求，只要有数据延迟容忍度，都应该优先考虑预聚合方案。

5.3 读写分离和分库分表是最后的大招，别轻易亮出来

当慢SQL是因为整体数据库资源不足导致时，业务方往往会把“读写分离”或者“分库分表”挂在嘴边。这两个方案都能解决问题，但都属于高成本、高复杂度的重构，不是简单的配置开关。

读写分离的前提是业务能接受主从延迟，至少能区分“强一致读”和“弱一致读”。比如订单详情页刚刚下单完成，用户立刻刷新，如果读请求被路由到了从库，而从库还没来得及同步最新订单，页面就会“凭空消失”，这种体验比响应慢还糟糕。所以做读写分离时，必须对核心读接口做严格的延迟容忍度评估，必要时强制走主库。

分库分表更是“上了船就很难下来”的决策。分片键的选择决定了未来所有查询的形态，一旦按 user_id 分片，所有按商家维度拉的查询都会变成跨片查询，SQL要改写，分布式事务要做，数据迁移要大半夜操作。所以我的原则是先排查是不是“查询一次拿太多数据”、是不是存在多余的排序和临时表、是不是索引设计有误，把这些基础优化做完了，确认单表数据量确实超过千万级别，写入压力也确实大到主库扛不住，再考虑分库分表。

6. 慢SQL优化中常见问题与复盘实录

6.1 慢SQL优化常见问题速查表

我整理了一些实际排查过程中最常被问到、也是最常见的问题，做成一个速查表，适合平时对照排查。

这张表不能当作标准答案来背，但能帮你快速建立排查的思路。真正到线上去解决问题时，方向往往比手段更重要。

6.2 一次因字符集不一致导致JOIN走不了索引的复盘

讲一个让我印象很深的真实案例。当时有个报表查询接口，响应时间从平时的300毫秒飙升到2.3秒，本来以为是数据量涨了，结果打开慢日志一看，是一条类似这样的JOIN查询：

sql复制SELECT d.bill_no, u.user_name
FROM order_detail d
INNER JOIN user_base u ON d.user_id = u.id
WHERE d.create_time >= '2024-11-01'
  AND d.create_time < '2024-12-01';

order_detail 和 user_base 都是千万级的大表，理论上 user_base.id 是主键，JOIN应该很快。但EXPLAIN结果显示，user_base 这张表的访问类型是 ALL，说明优化器没有用上主键索引。

排查到后面才发现，两张表的 user_id 字段虽然都能关联起来，但一张表是 utf8mb4 字符集，另一张是历史遗留的 latin1 字符集。MySQL在做JOIN的时候，为了比较两个不同字符集的值，会对其中一列做字符集转换，这个转换过程导致索引列被“加工”了，主键索引自然就用不上了。

当时的临时处理方案是让开发同学在JOIN条件里显式指定字符集，让转换发生在非索引列上，SQL立刻恢复到几十毫秒。长期方案则是走在线DDL工具把老表的字符集统一成 utf8mb4，并在代码评审规范里明确要求，新表统一使用 utf8mb4，从源头杜绝这种问题。这个经历也让我养成了一个习惯：凡是排查慢JOIN，第一反应永远是看两边的关联字段类型、长度和字符集是否完全一致。

6.3 我排查慢查询的习惯性动作

处理慢SQL多了之后，我总结了几个自己固定的动作：上线一个新功能前，先预估这个功能涉及的表的数据量，把核心查询语句跑一遍EXPLAIN；代码评审时重点看不带条件的 SELECT、SELECT *、大表JOIN、循环查库和深分页；上线后观察慢查询日志，如果同一个SQL在日志里连续三天出现，不管当时耗时不耗时，都说明它已经脱离了测试环境下的预期行为。

还有一个经验是，不要只盯着数据库，慢SQL往往是业务场景变化的前兆。比如原本只有几十个用户在用某个功能，突然一天有几千个用户涌入，访问模式和数据分布都变了，原来的执行计划不再适用。这时候你要做的可能不是改SQL，而是重新评估这个功能的量级，提前设计好容量。数据库优化不是一个一次性动作，它是一种持续跟进业务发展的习惯。

很多问题在业务量小的时候根本不会暴露，但SQL的写法、索引的设计、数据的冗余程度会在早期就决定系统未来的上限。上线前多花半小时写一条体面的SQL，可能比上线后每周花半天排查慢查询日志要有价值得多。