应重点关注innodb_data_writes和innodb_log_writes判断写io压力，innodb_buffer_pool_reads反映真实读io，而非innodb_buffer_pool_read_requests；缓存命中率低于99%才需优化，created_tmp_disk_tables与存储引擎io无关；用lsof定位活跃文件，结合iostat -x 1的w_await、aqu-sz交叉验证瓶颈。
直接看 Innodb_data_writes 和 Innodb_log_writes，别被 Innodb_buffer_pool_read_requests 迷惑
这个指标高只代表逻辑读频繁，不是磁盘忙。真正反映写 IO 压力的是 Innodb_data_writes（数据页写）和 Innodb_log_writes（redo 日志写）。每秒超过 500–1000 次写入，再结合 iostat -x 1 的 w/s 值明显偏高，基本可确认是写 IO 瓶颈。
读压力要看 Innodb_buffer_pool_reads（从磁盘读取页的次数），而不是 Innodb_buffer_pool_read_requests。缓存命中率公式是：Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)，低于 99% 才值得怀疑 buffer pool 不足或存在大范围扫描。
别盯着 Created_tmp_disk_tables——它反映临时表落盘，和 InnoDB 数据/日志文件的物理 IO 无直接关系，容易误判瓶颈来源。
用 lsof 定位 MySQL 正在狂写的到底是哪个文件
MySQL 不暴露 SQL 到文件路径的映射，但 OS 层能看见 mysqld 在操作什么文件。执行：lsof -p $(pgrep mysqld) | grep -E 'REG.*[W|DEL]'
重点关注这些类型：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
ib_logfile0或ib_logfile1：redo 日志写满轮转、innodb_flush_log_at_trx_commit=1导致高频 fsync -
ibdata1：说明innodb_file_per_table=OFF，所有表挤在一起，IO 无法按表归因 -
test/t1.ibd这类路径：对应具体表空间，可定位到某张表或分区 -
mysql-bin.000001：二进制日志写入，sync_binlog=1时也会显著增加 IO
配合 iostat -x 1 观察 %util 和 w_await，再比对 lsof 输出里高频出现的文件名，能快速圈定真实瓶颈文件。
iostat -x 1 看到的数字，哪些该信、哪些该忽略
iostat -x -k -d 1 是系统级快照工具，它不关联 MySQL 进程、不解析 SQL、也不区分日志写还是数据页写。你只能看到设备层宏观压力信号：
-
%util接近 100%、w_await持续 >20ms、aqu-sz（平均队列深度）长期 >5 → 磁盘响应已吃紧 -
svctm字段在现代内核中已失效，必须忽略 - 只看
w/s高，却没结合wkB/s和avgrq-sz，可能误判：4KB 小写密集型负载和 128KB 大块写对 SSD 的压力完全不同
它完全看不到请求来源：是 ib_logfile0 在狂写？还是某个大表导入触发脏页刷写？还是 mysqldump 正在拷贝？得靠前面的 lsof + SHOW ENGINE INNODB STATUS\G 的 FILE I/O 部分交叉验证。
调整 innodb_io_capacity 和 innodb_write_io_threads 之前，先看 aqu-sz
这两个参数必须协同调，否则一个设高了另一个没跟上，等于白调：
-
innodb_io_capacity应设为磁盘随机写 IOPS 的 50%~75%，不是标称值。例如一块标称 5000 IOPS 的 NVMe，实际稳定可用约 3500，设成 2500 更稳妥 -
innodb_io_capacity_max建议设为innodb_io_capacity的 2 倍，防止 checkpoint lag 触发紧急刷盘造成 IO 尖峰 -
innodb_write_io_threads默认是 4，SSD 上可提到 8～12，但必须匹配队列深度：用iostat -x 1观察aqu-sz，如果长期 >2 且w_await升高，说明线程数不够；但如果aqu-sz已经压到 0.3 以下，再加线程无意义，还可能增加上下文切换开销
innodb_adaptive_flushing 必须保持 ON（默认），关掉后无法根据 redo log 增长速率动态调节刷页节奏，大事务后必出尖峰。
