MySQL磁盘IO性能优化需从查询索引、缓冲配置、表结构和硬件适配四层面协同改进：优化索引避免全表扫描，合理设置innodb_buffer_pool_size（50%–75%内存）与日志参数，选用合适行格式及存储引擎，SSD下调高IO容量并分散IO负载。
MySQL磁盘IO性能优化的核心在于减少不必要的磁盘读写、提升数据访问局部性、合理利用缓存，并匹配硬件能力。重点不是盲目调大参数，而是从查询、索引、配置和存储结构四个层面协同改进。
优化查询与索引，减少物理IO
大部分磁盘IO来自全表扫描或索引失效。确保高频查询走有效索引，避免SELECT *、隐式类型转换、函数包裹字段等导致索引失效的情况。
- 用EXPLAIN分析慢查询，重点关注type是否为ALL（全表扫描）、rows是否远大于实际返回行数
- 为WHERE、JOIN、ORDER BY、GROUP BY中涉及的列建立复合索引，遵循最左前缀原则
- 对大表分页慎用OFFSET，改用基于游标的分页（如WHERE id > last_id LIMIT 20）
- 定期用pt-duplicate-key-checker检查冗余索引，用pt-index-usage分析索引实际使用率
调整InnoDB缓冲池与日志配置
InnoDB Buffer Pool是减少磁盘读的关键。其大小应占可用内存的50%–75%，但需为OS和其他进程预留空间。
- 设置innodb_buffer_pool_size = 60%～75% of total RAM（例如16G内存可设10G）
- 启用innodb_buffer_pool_instances（建议设为CPU核心数，但不超过8），降低并发争用
- 增大innodb_log_file_size（如256M–1G），减少checkpoint频率，降低redo log刷盘压力
- 将innodb_flush_log_at_trx_commit设为2（兼顾安全性与性能），配合sync_binlog=1000可进一步降低刷盘次数
合理规划表结构与存储引擎
磁盘IO效率受行格式、数据分布和引擎特性直接影响。
- 使用ROW_FORMAT=COMPACT或DYNAMIC（避免REDUNDANT），开启innodb_file_per_table便于空间回收
- 对只读或低频更新的大表，考虑归档到ARCHIVE引擎或分区表（按时间/ID范围），减少主表体积
- 冷热数据分离：将历史数据迁出主表，或用MySQL 8.0+的RECLASSIFY语法标记冷数据，触发自动页面淘汰
- 避免TEXT/BLOB列频繁更新，它们可能引发额外的溢出页IO；必要时拆到单独关联表
适配存储硬件与文件系统
再好的配置也受限于底层IO能力。SSD比HDD更适合随机读写，而配置需随之调整。
- SSD上可适当提高innodb_io_capacity（如1000–4000）和innodb_io_capacity_max（2000–8000），让InnoDB更激进地预读和刷脏页
- 挂载ext4/xfs时启用noatime,nodiratime，并确保使用XFS时开启inode64（避免单目录过大瓶颈）
- 将ibdata1、ib_logfile*、binlog、tmpdir分散到不同物理磁盘（或LVM条带卷），缓解IO竞争
- 禁用swap（swappiness=0），防止内存压力下InnoDB页被换出，引发严重IO抖动
不复杂但容易忽略。真正有效的IO优化，往往藏在一条没走索引的UPDATE里，或一个过小的buffer pool中。
