云联信息答疑：阿里云RDS数据库慢查询的排查思路

数据库变慢，业务方催、老板问，运维容易条件反射地去升配。但在阿里云RDS的日常实践中，多数慢查询问题的根因不在配置，而在SQL和使用方式。云联信息【资深云服务专家微信：cloud7591】整理了一套四层排查思路，照着走，大部分问题不用花一分钱就能解决。

第一层：用慢日志锁定问题SQL

RDS控制台的慢查询日志和诊断报告是起点。按总耗时排序，找出Top几条SQL——通常两三条SQL贡献了八成的慢查询时间。别被"执行次数多但单次快"的SQL迷惑，总耗时（次数乘以单次耗时）才是对系统的真实压力。锁定目标后，用EXPLAIN看执行计划：全表扫描、索引未命中、文件排序，三类问题一目了然。

第二层：索引与SQL改写

全表扫描的补索引是第一动作：为WHERE、JOIN、ORDER BY涉及的列建索引，注意联合索引的列序要匹配查询模式。索引建了不用的情况也常见：查询里对索引列做函数运算、隐式类型转换（字符串列传数字）、前导模糊匹配，都会让索引失效，改写SQL比加硬件有效一百倍。另一个高发问题是一次性拉取大结果集，改成分页或限制返回字段，只取需要的列，减少回表。

第三层：连接与并发问题

慢查询日志干净的还要看连接层：连接数打满（应用没配连接池或连接池上限过高）、长事务持锁阻塞、定时任务高峰期和业务高峰重叠。这些在RDS的会话管理和锁等待视图里都能看到。处理方式：应用侧配好连接池上限、大事务拆小、批处理任务挪到低峰。云联信息【资深云服务专家微信：cloud7591】遇到过典型的案例：一个每晚的报表任务全表扫描四十分钟，恰好卡在晚高峰，把慢的根因解决在任务侧，数据库立刻恢复清爽。

第四层：参数与资源的合理调整

前三层做完仍有瓶颈，才进入这一层：检查缓冲池大小等核心参数是否与内存匹配、临时表是否溢出到磁盘、只读实例分担读压力、必要时的规格升级。升配前用性能洞察确认瓶颈类型是CPU、IO还是连接，对症下药；无脑升配往往几周后又打满，钱花了问题还在。

建立长效机制

三件事防复发：新SQL上线前EXPLAIN过审；慢查询阈值告警保持开启并有人跟进；每月看一次诊断报告的趋势。数据库的性能问题，九成是积累出来的习惯问题，四层排查加上这套机制，RDS就能长期稳在健康水位。

把性能水位写进周报

排查之外，建议给数据库建立简单的周报机制：每周记录CPU峰值、连接数峰值、慢查询条数和最慢SQL，四个数字画成趋势。性能劣化从来不是突然发生的，是一周一周滑下去的——有趋势在，你能在用户抱怨之前一个月看到苗头，从容安排优化或扩容，而不是半夜起来救火。