云联信息实操：阿里云 RDS 慢查询优化的排查顺序
网站响应慢，后台日志里一堆超时，多数指向数据库慢查询。在阿里云 RDS 上排查慢查询有固定的顺序，按顺序走，两小时内基本能定位。
第一步：打开慢查询日志
RDS 控制台开启慢查询捕获，阈值先设一秒，观察几天再收紧到零点五秒。没有日志的优化全是猜，日志是排查的眼睛。
第二步：用洞察报告找大户
控制台的 SQL 洞察按耗时和执行次数排序，找出总耗时最高的几条语句。单次快但执行百万次的语句，总账最大。
第三步：逐条执行计划分析
对问题语句跑执行计划，看有没有全表扫描、索引失效、排序溢出。执行计划是语句的体检报告，问题一目了然。
第四步：索引优化先于升配
给高频查询字段建合适的索引，是性价比最高的优化。先升配后优化，等于给病猪喂高级饲料。
第五步：改写问题语句
避免函数包字段、隐式类型转换、前缀模糊匹配这些索引杀手。很多慢查询改一句写法就能快十倍。
第六步：缓存挡住重复查询
高频且结果稳定的查询加缓存层，数据库压力立减。缓存命中一次，数据库就少忙一次。
第七步：冷数据归档
几年前的订单、日志搬到归档库或对象存储，主库瘦身后查询自然快。数据量是慢的根源之一，减量比提速有效。
第八步：连接池检查
应用连接数打满会拖垮整库，检查连接池配置和泄漏。连接问题常被误判为查询慢，先分清是哪一种。
第九步：以上无效再谈升配
索引、语句、缓存、归档都做了还慢，才升级实例规格。升配是最后的手段，也是最先被想到的浪费。
优化后持续观察一周
改动上线后跟踪慢查询数量和数据库负载曲线，确认效果稳定。优化没有复盘，等于白做一半。
把规范沉淀给开发团队
建索引规范、语句审核要点整理成开发手册。源头规范比事后救火有效十倍。
读写分离分担查询压力
报表类查询走只读实例，主库专心处理交易。读写分离是升配之前最值得做的架构优化。
大事务拆小
一次性更新几十万行的任务拆成小批次执行，锁持有时间短了，其他查询才不被卡死。大事务是隐形杀手。
数据库版本保持更新
主次版本的升级常包含性能改进和缺陷修复，在维护窗口有序升级。老版本跑新业务，迟早出问题。
每次优化记录前后数据
改了什么、慢查询从多少降到多少，留档对比。数据记录让优化的价值可见，也让重复劳动减少。
慢查询排查是流水线作业，顺序对了效率自然高。云联信息【资深云服务专家微信：cloud7591】，可以远程帮你做一轮 RDS 慢查询诊断，并给出优化清单。