一、为什么要写一篇"完整思路"的文章？
在排查 MySQL 性能问题时，最常见的情况不是"不会查"，而是：
-
查得很乱
-
每次都从 SQL 开始
-
经常修到一半才发现方向不对
结果就是：
-
问题解决了，但说不清楚为什么
-
下次再来一遍，还是同样的混乱
真正有价值的不是某一次优化，而是一套稳定、可复用的排查思路。
这篇文章，就是我在多次线上问题中反复验证过的一套完整路径。
二、第一步：先判断是不是"性能问题"
这是很多人会跳过的一步，但非常关键。
我会先确认三件事：
-
数据库是不是"真的在慢"
-
还是请求在排队
-
或者连接已经耗尽
因为现实中经常出现：
-
CPU 不高
-
IO 不高
-
但系统不可用
这类问题，本质上不是性能，而是资源被占满。
如果一开始就当成"慢 SQL"，方向就错了。
三、第二步：优先看连接，而不是 SQL
这是我固定的第一检查点。
重点不是"多少连接"，而是：
-
有多少连接长期存在
-
连接是否及时释放
-
Sleep 连接是否异常偏多
一旦发现：
-
连接数持续上涨
-
新请求无法获取连接
那基本可以确定：
问题已经从"慢"升级为"不可用"
此时再优化 SQL，意义已经不大。
四、第三步：检查事务是否"活得太久"
如果连接异常，下一步一定是事务。
我重点关注的是：
-
是否存在长事务
-
是否有事务未提交
-
事务中是否夹杂复杂逻辑
长事务的危害往往被低估：
-
锁长期不释放
-
Undo 日志无法回收
-
连接被一直占用
很多数据库"越跑越慢"，根因就在这里。
五、第四步：确认锁有没有在悄悄排队
在事务之后，我会看锁。
因为大量慢 SQL，其实是在：
-
等行锁
-
等事务提交
而不是在执行。
锁问题的特点是：
-
单条 SQL 看起来没问题
-
Explain 也正常
-
但整体请求开始堆积
如果锁链被拉长，系统会迅速从"慢"演变成"卡"。
六、第五步：从内存和 IO 角度看系统状态
只有在前面几个都确认没问题后，我才会看内存。
重点关注的不是参数大小，而是：
-
Buffer Pool 命中率
-
是否频繁触发磁盘 IO
-
高峰期是否出现明显抖动
内存不足带来的问题，往往表现为：
-
SQL 时快时慢
-
高峰期性能骤降
-
难以稳定复现
这类问题，单靠改 SQL 很难解决。
七、第六步：最后才是 SQL 本身
到这一步，才是真正"调 SQL"的阶段。
但此时我关注的已经不是：
- 会不会走索引
而是：
-
SQL 在当前系统状态下是否合理
-
是否被环境放大
-
是否需要调整访问模式
很多 SQL 在"健康系统"中是没问题的，
问题出在系统已经不健康了。
八、为什么这个顺序非常重要？
因为这是一个从"系统级"到"语句级"的排查路径：
-
连接（有没有空位）
-
事务（有没有人一直占着）
-
锁（有没有人在排队）
-
内存 / IO（系统是不是开始吃力）
-
SQL（最后才看细节）
顺序一旦反了：
-
容易治标不治本
-
很容易反复出问题
九、我从这些问题中得到的一个结论
绝大多数 MySQL 性能问题，本质上不是 SQL 写得差，而是系统状态已经被拖垮。
数据库只是最先暴露问题的地方。
当你能从系统角度去看待性能问题时：
-
排查速度会明显提升
-
优化效果更稳定
-
问题不容易反复
十、总结一句话
MySQL 性能排查，拼的不是技巧，而是顺序和视角。
先保证系统能"顺畅流动"，
再考虑"怎么跑得更快"，
你会少走很多弯路。
本回答内容仅供参考，不构成专业建议。实际操作中可能存在风险，请根据个人需求和实际情况谨慎判断并采取行动。对于因使用或依赖本回答内容而产生的任何直接或间接损失，概不负责。