慢查询日志是定位MySQL性能问题的起点，需先通过SET GLOBAL slow_query_log=1和long_query_time=0.5临时开启并设阈值，查slow_query_log_file确认路径；禁用log_queries_not_using_indexes防日志爆炸；用mysqldumpslow -s t -t 10分析前10耗时SQL；持久化须改my.cnf；配合Threads_running、Handler_read_rnd_next、iostat等指标综合排查根因。
先看 slow_query_log，别一上来就 explain
慢查询日志是 MySQL 自己“招供”的第一现场，不是辅助手段，是起点。线上响应变慢，90% 的根因就藏在没走索引或执行过久的 SQL 里。
临时开启只需两行命令：SET GLOBAL slow_query_log = 1，SET GLOBAL long_query_time = 0.5（单位秒）。注意：MySQL 实际按 0.5 秒截断，不是四舍五入——超过 500ms 就记；但不会记录毫秒级抖动。
- 日志路径用
SHOW VARIABLES LIKE 'slow_query_log_file'查，别硬猜路径 -
log_queries_not_using_indexes别长期开着，它会把所有未走索引的语句全塞进日志（哪怕只查 3 行），磁盘可能几小时就爆 - 分析时优先用
mysqldumpslow -s t -t 10 /var/lib/mysql/mysql-slow.log，按总耗时排前 10 条，比人工翻快得多 - 重启后
SET GLOBAL会失效；若要持久化，必须改my.cnf并重启，但生产环境慎用——日志 IO 压力可能反超业务
查 Threads_running，比看 PROCESSLIST 更快定位并发压力
Threads_running 是真实干活的线程数，只统计正在执行 SQL 的连接。它比满屏 Sleep 状态的 SHOW FULL PROCESSLIST 更准、更早暴露瓶颈。
执行 SHOW GLOBAL STATUS LIKE 'Threads_running'，结果 >32 就该警惕，>64 基本说明 CPU 或锁已扛不住。这时再配合 SHOW GLOBAL STATUS LIKE 'Threads_connected' 对比：
- 如果后者远大于前者，说明大量连接空闲挂着，问题大概率在应用层没释放连接池
- 如果两者接近且持续高位，重点盯
Innodb_row_lock_waits和Innodb_buffer_pool_reads - 别只盯着
State = Sending data—— 它可能只是表扫描慢，而真正卡住的是前面那个没提交的事务
用 iostat -x 1 看磁盘，别被 top 的 %CPU 迷惑
top 里 mysqld 占 CPU 高，不等于它真在计算。InnoDB 很多时候是“假忙”：卡在等磁盘响应，CPU 在空转，top 却把它标为 R（Running）状态。
执行 iostat -x 1 5 后盯死两列：
-
%util接近 100% → 磁盘几乎没空闲时间，I/O 已饱和 -
await超过 10ms（SSD）或 30ms（HDD）→ 单次 I/O 响应变慢，可能是存储层问题（如云盘突发配额耗尽、NFS 挂载抖动） - 常见陷阱：
%util不高但await高？别急着调 MySQL 参数，先查基础设施——RAID 卡电池是否失效、云厂商后台是否在做快照 - 就算磁盘不忙，
innodb_io_capacity设太低也会压低刷脏页节奏，导致缓冲池命中率下降、逻辑读暴涨，最终又推高 CPU
Handler_read_rnd_next 高，说明 SQL 在回表或全表扫描
Handler_read_rnd_next 是比 EXPLAIN 的 rows 更真实的扫描成本指标。它记录的是“通过主键或索引查找后，再随机读取数据行”的次数。值高基本等于回表严重或索引根本没生效。
查指标：SHOW GLOBAL STATUS LIKE 'Handler_read%'，重点关注两个比值：
-
Handler_read_rnd_next / Handler_read_next > 0.1→ 覆盖索引缺失，SELECT 字段太多，或联合索引顺序没对上最左前缀 -
Handler_read_first持续涨 → 大量ORDER BY或GROUP BY没走索引，需要补排序字段索引 - 哪怕
EXPLAIN显示type = ref、key有值，只要Handler_read_rnd_next高，就说明优化器选了索引，但还得来回找数据行——性能照样差 - 高频查询务必让所有 SELECT 字段都落在联合索引里，避免
SELECT *或额外字段触发回表
真正卡住 MySQL 的，往往不是单条巨慢 SQL，而是多个中等耗时查询叠加、锁等待传导、或缓冲池配置失当导致的连锁反应。排查时别陷进某一条 SQL 的 EXPLAIN 里出不来，先拉通看 Threads_running、Handler_read_*、iostat 和慢日志这四条线是否指向同一个根因。
