%wa持续>30%表明磁盘IO瓶颈，需立即用iostat -x 1查%util>70%、await>10ms及r/s/w/s异常，再用iotop -o确认mysqld主导IO，df -h检查磁盘空间是否超90%，并结合Innodb_buffer_pool_reads>100/秒等指标综合判断。
top里%wa持续>30%就该停掉其他操作
这不是CPU或内存问题，是磁盘在拖住整个系统。MySQL hang住时，top右上角的%wa（iowait）如果稳定在 30% 以上，说明 CPU 正在空等磁盘响应——这时候连kill -9 mysqld 都可能不生效，因为信号队列卡在内核 IO 层。
立刻执行：iostat -x 1 看实时指标，重点盯住三样：
-
%util> 70% 且持续不回落 → 磁盘已饱和 -
await> 10ms → 请求排队严重，不是设备慢就是负载过重 -
r/s或w/s异常高（比如 SSD 上 w/s 超 5000）→ 很可能是小事务高频刷盘
别急着进 MySQL 查状态，系统层已经给出明确信号：IO 是瓶颈，不是 SQL 写得烂，也不是连接数太多。
iotop -o确认mysqld是不是真凶
iotop -o 只显示正在做 IO 的进程，如果看到 mysqld 占用 90%+ 的读写带宽，基本可以锁定问题源。但要注意两个干扰项：
- 备份进程（如
mysqldump、percona-xtrabackup）也在跑 → 先停掉再观察 - 磁盘空间
df -h显示 Use% > 90% → 内核会触发写阻塞，%util会虚高，mysqld实际没干多少活，只是被卡住
如果 iotop 显示 mysqld 持续写 ib_logfile0 或读大量 .ibd 文件，说明 InnoDB 正在拼命换页或刷日志，下一步要查参数配置。
查Innodb_buffer_pool_reads是否持续>100/秒
进 MySQL 执行：SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';，隔 10 秒再查一次，算差值。如果每秒从磁盘读页数 > 100，Buffer Pool 基本失效了。
再看命中率：(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) * 100，低于 95% 就危险。常见原因：
-
innodb_buffer_pool_size设太小（比如物理内存 64G 只配了 8G） - 业务突增导致热点数据挤出 Buffer Pool，而脏页又来不及刷，引发连锁换页
-
innodb_io_capacity设错（SSD 却按 HDD 设成 200），后台刷脏太慢，Buffer Pool 积压 dirty page，前台被迫同步刷盘
此时 SHOW ENGINE INNODB STATUS\G 里的 FILE I/O 段会出现持续不为 0 的 pending normal aio reads/writes，这是最直接的证据。
log_queries_not_using_indexes=ON才能抓到“快但伤IO”的SQL
慢查询日志默认只记超时的语句，而真正打满 IO 的，往往是那些执行只要几毫秒、但并发一高就扫穿全表的 SQL。它们根本不会进 slow_query_log。
必须开：SET GLOBAL log_queries_not_using_indexes = ON; 并确保 long_query_time = 0（否则旧版本不生效）。之后用 mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log 看高频无索引查询。
典型陷阱包括：
-
WHERE YEAR(create_time) = 2024→ 函数导致索引失效 -
WHERE user_id = '123'（user_id 是 INT）→ 隐式类型转换 -
WHERE name LIKE '%abc'→ 左模糊无法走 B+ 树
这些语句单次快，但并发 100+ 时，Handler_read_rnd_next 和 Created_tmp_disk_tables 会飙升，IO 直接拉满。
真正难处理的从来不是“明显慢”的 SQL，而是那些看起来完全合法、执行计划也正常，却因统计信息过期、参数误配或并发放大效应，在特定时刻把磁盘 IO 推到 100% 的操作。排查时系统指标永远比数据库日志更早报警，别等 SELECT 都卡住才想起看 iostat。
