MySQL 问题定位需按“现象→指标→逻辑”顺序收缩范围：先查连接状态（SHOW PROCESSLIST、Threads_*）、再看系统与 MySQL 性能指标（CPU、I/O、缓冲池命中率）、接着分析慢查询（慢日志 +EXPLAIN）、最后验证锁与事务（INNODB_TRX、LOCK_WAITS、INNODB STATUS）。
MySQL 问题快速定位，核心是“从现象反推路径”，先看症状、再查指标、最后验逻辑。不盲目重启，也不直接翻日志——而是按顺序收缩排查范围。
看连接与会话：是否卡在入口？
很多“慢”或“连不上”其实不是 SQL 问题，而是连接层被堵住。优先执行：
- SHOW PROCESSLIST; —— 查看当前活跃会话，重点关注 State 为 Waiting for table metadata lock、Sending data、Locked 的线程；长时间 Sleep 但数量暴涨，可能是应用没正确释放连接
- SHOW STATUS LIKE ‘Threads_%’; —— 关注 Threads_connected（当前连接数）和 Threads_running（真正干活的线程），若后者远小于前者，说明大量请求在排队或阻塞
- 检查 max_connections 设置是否过低，或应用端连接池配置是否激进（如 minIdle 过高 + 连接未归还）
查性能指标：有没有资源瓶颈？
用系统视角确认 MySQL 是否在“喘不过气”：
- 用 top / htop 看 mysqld 进程 CPU 和 内存占用；CPU 持续 >90% 且 load 高，大概率有慢查询或锁争用
- 用 iostat -x 1 观察 %util 和 await：若磁盘忙、await 显著升高（>50ms），结合 innodb_io_capacity 看 I/O 是否饱和
- 查 MySQL 内部指标：SHOW GLOBAL STATUS LIKE ‘Innodb_buffer_pool_%’; 看命中率（Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)），低于 99% 就要警惕缓存不足
抓慢查询：谁在拖慢整体？
开启并分析慢日志是最直接的线索来源：
- 确认慢日志已启用：SHOW VARIABLES LIKE ‘slow_query_log%’; 和 long_query_time（建议临时设为 1 秒快速捕获）
- 用 mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log 快速汇总耗时 Top 10 的 SQL
- 对高频慢 SQL，用 EXPLAIN FORMAT=JSON 查执行计划，重点看 type（是否全表扫描）、key（是否命中索引）、rows（预估扫描行数）、extra（是否 Using filesort / temporary）
验锁与事务：有没有人在“占着茅坑”？
死锁、长事务、未提交事务是隐形杀手：
- SELECT * FROM information_schema.INNODB_TRXG —— 查当前运行中的事务，关注 trx_state、trx_started（时间过久需警惕）、trx_mysql_thread_id
- SELECT * FROM information_schema.INNODB_LOCK_WAITSG —— 直接看到谁在等锁、被谁阻塞
- SHOW ENGINE INNODB STATUSG —— 在 LATEST DETECTED DEADLOCK 区域找最近死锁详情；在 TRANSACTIONS 部分看是否有长时间未提交事务
