磁盘io瓶颈需分层定位、精准干预：先确认是否真瓶颈，再从硬件、mysql配置、sql和文件系统四层协同优化。
磁盘 IO 成为瓶颈时，核心不是“换硬盘”，而是分层定位、精准干预：先确认是不是真瓶颈，再从硬件、MySQL 配置、SQL 和文件系统四个层面协同优化。
第一步：确认是否真是磁盘 IO 瓶颈
高延迟 ≠ 磁盘慢，误判会导致白忙活。要交叉验证：
- 用 iostat -x 1 看 %util 是否持续 >90%、await 显著高于 svctm、r/s 或 w/s 异常偏高；
- 查 MySQL 缓冲池命中率：innodb_buffer_pool_read_requests / (innodb_buffer_pool_read_requests + innodb_buffer_pool_reads)，低于 95% 说明内存不足，大量读落到磁盘；
- 看 SHOW GLOBAL STATUS 中 Innodb_data_reads 和 Innodb_data_writes 是否随业务峰值剧烈增长；
- 用 ps -eo pid,comm,pcpu,psr,iowait 观察 mysqld 进程的 iowait 是否持续 >10%。
第二步：硬件与存储层快速见效
这是提升下限最直接的一环：
- 用 SSD（优先 NVMe）替代 HDD，随机 IOPS 可从百级跃升至万级；
- 数据文件（.ibd）、redo log（ib_logfile*）、binlog 分开存到不同物理设备，避免争抢；
- RAID 选 10，不选 5/6——写惩罚小、并发吞吐高；
- 文件系统用 XFS 或 ext4，挂载参数加 noatime,nobarrier（确保有 UPS 或 BBU 时才关 barrier）。
第三步：MySQL 关键参数调优
目标是让数据尽量留在内存、让日志写得更聚合、让刷脏页更可控：
- innodb_buffer_pool_size 设为物理内存的 60%–80%，并开启预热：innodb_buffer_pool_load_at_startup = ON；
- innodb_log_file_size 增大到 1–2GB（如 2G），减少 checkpoint 频率，缓解写放大；
- 根据安全要求调整持久化策略：innodb_flush_log_at_trx_commit = 2（日志写 OS cache，每秒刷盘）+ sync_binlog = 1000；
- SSD 环境设 innodb_flush_neighbors = 0，禁用邻接页刷新；
- 设 innodb_io_capacity 匹配磁盘能力（SSD 通常 2000–4000，HDD 200–400）。
第四步：SQL 与表结构减少无效 IO
很多“IO 高”其实是低效 SQL 反复触发全表扫描或临时表落盘：
- 避免 SELECT *，只取必要字段，降低单次读页量；
- 为高频 WHERE / ORDER BY / JOIN 字段建复合索引，争取 Using index（覆盖索引）；
- 检查慢查询执行计划，警惕 type: ALL、Using filesort、Using temporary；
- 大表分页不用 LIMIT offset, size，改用游标式查询（WHERE id > last_id LIMIT N）；
- 调大 tmp_table_size 和 max_heap_table_size，避免 Created_tmp_disk_tables 暴涨。
不复杂但容易忽略。优化 SQL 磁盘 IO，本质是让热数据驻留内存、让写操作批量聚合、让读请求一次命中——硬件、配置、SQL 三者缺一不可。
