1. 先别急着看SQL，从现象倒推问题边界线上SQL昨天50毫秒，今天突然5秒，数据库CPU飙到90%。这几乎是每个DBA或后端开发都会遇到的典型“性能悬崖”问题。很多人第一反应是去分析SQL执行计划，这没错，但顺序错了。直接扎进SQL细节，很容易在几百行代码里迷失方向，浪费宝贵的故障响应时间。更高效的做法是，先根据现象划定排查的边界。CPU 90%是一个强烈的系统级信号，它告诉你问题大概率不是“偶发性慢”，而是“持续性资源争抢”。5秒对比50毫秒，是100倍的性能劣化，这通常意味着执行路径发生了根本性改变，比如索引失效、全表扫描、错误的连接方式，或者执行计划本身“跳变”了。所以，排查的第一步不是看SQL怎么写，而是回答这几个问题：是只有这一条SQL慢，还是整个数据库实例都慢？这决定了问题是语句级还是实例级。慢查询是持续出现，还是间歇性出现？持续出现往往指向执行计划变更或数据量突变；间歇性出现则可能和锁、资源竞争、定时任务有关。5秒的查询，其时间主要消耗在哪个环节？是在等待（Waiting），还是在执行（Executing）？这几个问题的答案，能帮你快速排除一大片无关区域，把火力集中在最可能的原因上。我一般的习惯是，接到这种告警，前10分钟不直接动SQL，而是先拉监控、看日志，把问题的“时空范围”框死。2. 构建五分钟快速诊断清单：从外围到核心框定范围后，需要一套可重复执行的诊断动作。下面这个清单，我称之为“五分钟快速诊断清单”，它按照从外围系统到数据库核心的顺序展开，能帮你用最短时间找到最可能的疑点。2.1 第一步：确认基础监控与负载不要依赖感觉，直接看数据。数据库整体监控：连接数、QPS（每秒查询数）、TPS（每秒事务数）是否在正常范围？如果只有那条SQL慢，但整体QPS没变，说明是局部问题；如果整体QPS也下降了，可能这条慢SQL阻塞了其他请求。主机资源监控：除了CPU，还要看内存使用率、磁盘IO（尤其是读IOPS和延迟）、网络流量。有时磁盘IO瓶颈也会导致CPU因等待IO而“空转”显示利用率高。确认时间点：问题发生的确切时间点是什么？和昨天的同一时间点对比，业务流量是否有巨大差异（如促销活动）？如果没有，那么基本可以排除业务流量突增的影响。2.2 第二步：捕获“犯罪现场”的快照你需要拿到那条正在运行的、消耗5秒的SQL的实时状态。使用数据库性能视图：这是最直接的手段。以MySQL为例，立即查询information_schema.PROCESSLIST或SHOW FULL PROCESSLIST，找到那条状态为Executing或Sending data且时间很长的连接。记录下它的Id