一、慢的时候，先别急着改 SQL
数据库变慢时，很多人的第一反应是：
-
看慢 SQL
-
看索引
-
改语句
但在真实生产环境里，大量"慢"的问题，并不是 SQL 本身造成的。
如果顺序错了，你很可能：
-
花几个小时调 SQL
-
最后发现根因在别处
下面这 5 个点，是我线上排查时固定的第一顺序。
二、第 1 个看：连接是否被占满
这是优先级最高的一项。
我会第一时间确认：
-
当前连接数
-
活跃连接数
-
Sleep 连接数量
如果看到：
-
连接数接近上限
-
大量连接长期不释放
那问题通常已经不是"慢"，而是"资源耗尽"。
此时再看 SQL，意义不大。
三、第 2 个看：有没有长事务没结束
如果连接数异常，下一步我一定看事务。
重点关注的是：
-
事务持续时间
-
是否存在未提交事务
-
事务是否持有锁
长事务的危害在于：
-
锁不释放
-
Undo 无法回收
-
连接一直被占用
这是导致数据库"越跑越慢"的典型元凶。
四、第 3 个看：锁在不在"悄悄排队"
很多 SQL 慢，其实不是在执行，而是在等。
我会关注：
-
是否存在锁等待
-
是否有事务互相阻塞
-
锁链是否被拉长
一旦出现锁等待：
-
后续请求会不断堆积
-
看起来像是数据库整体变慢
但本质上，是某个点堵住了整个通道。
五、第 4 个看：内存是否已经顶不住了
如果连接、事务、锁都正常，我才会去看内存。
重点不是参数大小，而是：
-
Buffer Pool 命中率
-
是否频繁读磁盘
-
IO 等待情况
当内存不够用时：
-
SQL 执行时间抖动
-
高峰期性能急剧下降
这是最容易被误判为"偶发慢 SQL"的情况。
六、第 5 个看：请求是不是被"拖慢"的
最后我才会看 SQL 本身。
但关注点是：
-
执行耗时是否突然变长
-
是否受环境影响
-
是否在高峰期明显变慢
如果 SQL 在低峰很快，高峰很慢：
那问题往往不在 SQL，而在系统负载。
七、为什么我要按这个顺序？
因为这是一个从"系统不可用"到"语句问题"的排查路径：
1️⃣ 连接（有没有空位）
2️⃣ 事务（有没有人一直占着）
3️⃣ 锁（有没有人在排队）
4️⃣ 内存（是不是开始打 IO）
5️⃣ SQL（最后才看细节）
顺序一旦反了，很容易白忙一场。
八、总结一句话
数据库慢的时候，最怕一上来就盯着 SQL。
真正高效的排查，是先判断：
-
系统还能不能正常"流动"
-
再考虑"怎么让它跑得更快"
把这 5 个地方看明白，
你会少走很多弯路。
本回答内容仅供参考，不构成专业建议。实际操作中可能存在风险，请根据个人需求和实际情况谨慎判断并采取行动。对于因使用或依赖本回答内容而产生的任何直接或间接损失，概不负责。