应查slow_log中rows_examined远大于rows_sent的语句，因其虽执行快但引发大量物理读，导致iops飙升；需先确认slow_query_log=on并设long_query_time≤0.1，重点关注rows_examined>10000且rows_sent极小的查询。
查 slow_log 里执行时间长但扫描行数多的语句
磁盘 IOPS 飙升往往不是因为 SQL 执行慢，而是因为它读了太多数据页——哪怕执行只花 100ms，如果 rows_examined 是几百万，就会反复触发物理读。MySQL 的 slow_log（需提前开启）会记录 rows_examined 和 rows_sent，这两个值差距大，就是典型信号。
- 确认是否启用了慢日志：
SHOW VARIABLES LIKE 'slow_query_log'；没开就先设SET GLOBAL slow_query_log = ON，并调低long_query_time（比如设为 0.1） - 重点看
rows_examined> 10000 且rows_sent很小（比如 - 用
mysqldumpslow -s t -t 10 /var/lib/mysql/localhost-slow.log快速聚合排序，比直接grep更准
用 Performance Schema 定位高逻辑读/物理读的会话
慢日志有延迟，且可能漏掉“快但重”的语句（例如每秒跑几十次、每次扫几千行的短查询）。Performance Schema 能实时抓取 IO 消耗，更准：
- 先确保启用：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'wait/io/file/%'和'wait/io/table/%' - 查当前物理读最高的前 5 个会话：
SELECT THREAD_ID, COUNT_STAR, SUM_TIMER_WAIT, SUM_NUMBER_OF_BYTES_READ FROM performance_schema.events_waits_summary_by_thread_by_event_name WHERE EVENT_NAME = 'wait/io/file/innodb/innodb_data_file' ORDER BY SUM_NUMBER_OF_BYTES_READ DESC LIMIT 5 - 再用
THREAD_ID关联performance_schema.threads找出对应PROCESSLIST_ID，然后SHOW PROCESSLIST看 SQL
注意 autocommit=0 + 大事务导致的隐式锁表和重复读压力
有些 SQL 单看不重，但放在长事务里会连锁放大 IO：InnoDB 在 REPEATABLE READ 下为保证一致性，可能要回溯多个版本的 undo log，引发大量随机读；同时未提交事务会阻止 purge 线程清理旧版本，导致 buffer pool 命中率下降，进一步推高物理读。
- 检查长时间未提交的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60 - 特别留意
trx_isolation_level = 'REPEATABLE READ'且trx_rows_locked > 10000的记录 - 应用层避免在事务里做 HTTP 调用、文件读写等阻塞操作——这类事务常卡住十几秒，期间所有新查询都得读老版本
区分 SSD 和 HDD 场景下的 IOPS 解读偏差
同一句 SELECT * FROM orders WHERE user_id = ? 在 HDD 上可能产生 200+ IOPS，在 NVMe SSD 上可能只有 20，但监控看到的是绝对数值。如果 DB 迁移后 IOPS 突然“飙升”，未必是 SQL 变差，可能是监控工具没适配新设备的队列深度或延迟特性。
- 用
iostat -x 1看%util和await：若await始终 - 对比
r/s（读 IOPS）和rkB/s：如果 r/s 高但 rkB/s 低（比如 1000 IOPS / 4MB/s），说明大量单页随机读，大概率是缺少索引或索引失效 - 不要只盯 Grafana 里的 IOPS 曲线峰值——要下钻到对应时间点的
performance_schema.events_statements_history_long，找那几分钟内ROWS_EXAMINED累计最高的 SQL
真正难定位的，往往是那些不报错、不进慢日志、EXPLAIN 显示走了索引、但实际因索引区分度差或统计信息过期，导致优化器选了“假高效”路径的语句。这种必须结合 performance_schema.table_io_waits_summary_by_table 和真实 buffer pool 命中率交叉验证。
