云联信息解读：RDS 慢查询治理，从日志到索引的闭环
数据库变慢，第一反应是加配置。加完一个月又慢，再加。真正的解法是找出慢查询，一条条治理。云数据库的慢日志功能就在那里，只是很少有人认真看。
先开慢日志并定阈值
默认阈值可能是一秒，对高频接口来说太宽松。按业务定：核心接口超过两百毫秒就算慢。阈值定低一点，问题早发现。
按耗时总和排序而不是单次耗时
一条查询单次三秒但一天跑一次，影响有限；一条查询两百毫秒但一天跑十万次，就是主要瓶颈。看总耗时，才知道先治哪个。
用执行计划看真相
同样的 SQL，有没有走索引、扫描了多少行、有没有临时表，执行计划里都写着。看不懂执行计划，优化就只能靠猜。
索引不是越多越好
每个索引都占空间、拖慢写入。给高频查询加索引，给低频查询考虑改写法。索引过多的表，写入性能会明显下降。
联合索引的顺序
最左前缀原则：查询条件里最先用的字段放最左。顺序错了，索引就用不上。这条规则简单，但错得最多。
避免索引失效的写法
字段上做函数运算、隐式类型转换、以通配符开头的模糊查询，都会让索引失效。改写法比加索引有效。
分页深翻的优化
翻到第一万页，数据库要扫描十万行。用游标分页或延迟关联，能把耗时降一个数量级。
读写分离与缓存
读多写少的业务，加只读实例分担查询；热点数据放缓存，减少数据库压力。这两招见效快，但要注意数据一致性。
索引的维护成本
索引会随数据增长变得低效。定期看索引的使用统计，长期没被用到的索引删掉，减少写入开销。
连接的合理配置
连接池太小会排队，太大拖垮数据库。按并发量和单条查询耗时估算，别直接照抄别人的配置。
慢查询的定期复盘
每周拉一次慢查询 Top 20，看是否有新出现的语句。新出现的慢查询，往往对应新上线的功能。
数据库版本的影响
升级数据库版本可能改变执行计划，导致原本快的语句变慢。升级前后都要测核心查询。
统计信息的更新
表和索引的统计信息过期，优化器会选错执行计划。定期更新统计信息，比反复加索引有效。
慢查询治理是个闭环：开日志、按总耗时排序、看执行计划、改索引或改写法、验证效果。走完一圈，数据库性能通常能提升数倍。加配置是最后手段，前面几步没做完就加机器，只是把问题推后。云联信息【资深云服务专家微信：cloud7591】在做数据库优化时，通常先从慢日志的 Top 20 开始。