我是小耶，干运营半路出家的野生DBA——写功课只是为了我踩过的坑，你们别再踩了！
你们遇到过这种情况吗？业务反馈页面转圈，登录数据库一看，CPU 100%。但不知道是哪个SQL干的。
这时候别慌，三条命令依次用。
1. 先看当前在跑的查询
sql
SHOW PROCESSLIST;
结果里找Command列为Query，Time列数值大的那些。Time表示执行了多少秒，越大越可疑。拿到Id，可以直接KILL <id>。
2. 打开慢查询日志（提前做）
MySQL设置：
text
slow_query_log = ON
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log
超过2秒的SQL会被记录。每天上班第一件事：看一眼昨天的慢查询日志，别等用户投诉。
bash
mysqldumpslow -s t /var/log/mysql/slow.log
-s t按时间排序，最慢的排前面。
3. 抓到慢SQL后，用EXPLAIN分析
sql
EXPLAIN SELECT ...;
重点看三列：
type：ALL是全表扫描（危险），ref或range是走索引（还行），const是最优rows：预估扫描的行数，越大越慢Extra：出现Using filesort或Using temporary，说明有排序或临时表，通常需要优化
顺手记一个组合拳
sql
EXPLAIN FORMAT=JSON SELECT ...;
输出JSON格式，能看到更详细的成本估算。适合出事故后写复盘报告用。
小耶在手，SQL不愁。
你今天慢查询日志里抓到最慢的SQL跑了多少秒？
