RDS 慢查询拖慢业务？从慢日志定位到索引优化的 6 步做法

慢查询是最常见的数据库性能问题：接口偶尔变慢、CPU 周期性冲高、连接数慢慢涨上去，最后往往都指向几条没有走好索引的 SQL。与其凭感觉加索引，不如按固定流程先定位、再验证、最后上线，6 步基本能覆盖大多数场景。

第一步，先确认慢的是哪几条。不要只看业务报错时间，要到数据库的慢查询日志里按执行次数和总耗时排序，找出出现频率高、单次耗时长、扫描行数远大于返回行数的 SQL。只优化一条偶发慢 SQL 意义不大，优先处理高频 SQL。

第二步，看执行计划。拿到 SQL 后用 EXPLAIN 看它实际走了什么：有没有用上索引、访问类型是全表扫描还是范围扫描、预估扫描行数是多少、是否出现临时表和文件排序。执行计划是判断依据，不是猜测；同一条 SQL 在不同数据量下计划可能完全不同，所以要在接近生产数据量的环境看。

第三步，区分三类根因。第一类是缺索引：WHERE 条件、JOIN 关联列、ORDER BY 排序列上没有合适索引，导致全表扫描。第二类是索引失效：对索引列做函数运算、隐式类型转换、LIKE 以百分号开头，都会让索引用不上。第三类是写法问题：SELECT * 拉回大量无用列、分页越翻越深、在循环里逐条查库（N+1），这些靠加索引解决不了。

第四步，对症下药。缺索引时按“等值条件在前、范围条件在后、排序列尽量顺带”的顺序建复合索引，一次只加一个，改完立刻复测。索引失效时先改写法：去掉不必要的函数、统一字段类型、把前导模糊查询改成全文检索或业务侧分词。分页深翻时改用游标分页，用上一页最后一条的主键或时间戳做条件，避免 OFFSET 越来越大。

第五步，上线前做三项验证。先在测试环境复测执行计划和耗时，确认扫描行数明显下降；再检查写入影响，索引不是越多越好，每个索引都会拖慢插入和更新；最后确认回滚方案，索引变更要能快速删回，不能靠“先上再说”。生产变更尽量选业务低峰期，避开大促和批量任务窗口。

第六步，上线后持续观察。看慢日志里这条 SQL 是否消失、接口 P95 耗时是否回落、CPU 和慢查询数量是否同步下降。如果只是单次变快但总量没降，说明还有同类 SQL 没找全，要回到第一步重新排序。另外要定期复查：数据量增长后，原来够用的索引可能不再够用，慢查询治理是周期性工作，不是做一次就结束。

常见误区要避开：一是上来就加索引，三个单列索引不等于一个好的复合索引；二是只看单次耗时，忽略执行频率和扫描行数；三是把所有逻辑都推给数据库，循环查库、拉全表到应用层过滤，本质是应用层问题。按“定位、看计划、分根因、改写法或索引、验证、上线观察”走一遍，大多数慢查询都能在不改架构的情况下解决。