慢 SQL 治理闭环：从慢查询日志到索引优化的标准动作

慢 SQL 是慢性病，不是急症

线上出大故障时大家会突击优化一波，但慢 SQL 的真正危害是「温水煮青蛙」：每个新版本多几条全表扫描，半年后数据库 CPU 常年 80%，所有人习以为常。慢 SQL 治理的要点是把它做成例行闭环而不是一次性运动。这篇给一套可落地的标准动作。

一、采集：慢查询日志的正确配置

PostgreSQL 配置三件套：log_min_duration_statement = 200（200ms 以上进日志）、log_lock_waits = on（锁等待单独记录）、配合 pg_stat_statements 扩展（聚合视图，TOP 查询一目了然）。MySQL 则开 slow_query_log 配 long_query_time。

两个配置坑：阈值不能设太严（1ms 会把日志撑爆也没人看，200ms 是告警与优化的分界）；pg_stat_statements 的均值会掩盖长尾——按 total_time 和 max_time 两个维度各看一遍。

二、定位：三种最常见的慢因与对应动作

1. 缺索引/索引失效：EXPLAIN 看 Seq Scan，结合字段选择性判断。加索引前先看写入放大的代价（写多读少的表加索引要权衡），复合索引注意最左前缀；

2. 回表过多：索引命中但取数列太多——覆盖索引（把查询列纳入索引）是性价比最高的优化，实测常见 5~10 倍提升；

3. 优化器选错计划：统计信息过期导致。ANALYZE 一把后复查；仍选错则用提示或重写 SQL（如 IN 大列表改 JOIN、隐式转换消除）。

一个容易被忽视的元凶：隐式类型转换。字符串字段用数字查、编码不一致的 JOIN，索引直接失效。这类问题 EXPLAIN 里看不出异常，要对比字段的实际类型。

三、治理闭环：让慢 SQL 不再回来

单点优化容易，防回潮靠机制：

1. 上线前拦截：新 SQL 进生产前跑 EXPLAIN 评审，开发规范里写死「禁止无索引的查询模式」（如前导通配符 LIKE）；

2. 周度榜单：pg_stat_statements 的 TOP10 变化周报进团队群，榜上有名的 SQL 当周消化；

3. 容量联动：慢 SQL 治理与容量规划联动——CPU 水位下降是最诚实的验收指标。

四、量化的验收标准

治理前后的可量化对比：P95 查询延迟、数据库 CPU 水位、慢查询日均条数。我们的经验值：一轮完整治理（两个月、每周两小时投入）通常能让数据库 CPU 下降 15~30 个百分点，慢查询条数降一个量级。

结语

慢 SQL 治理是「采集 → 定位 → 优化 → 防回潮」的循环。把每一步做成例行（日报、榜单、上线评审），数据库就能长期跑在健康水位上——这比任何单次抢救都值钱。