当 MySQL 出现频繁的磁盘 IO 时，MySQL 内存参数调优往往是首要的解决方向。但调优前必须明确边界：并非所有磁盘 IO 都能靠内存解决，例如数据量远超内存、或存在大量随机写入时，内存参数的作用会受限。本文以实操为导向，先帮你判断哪些场景适用，再给出具体的参数调整步骤。
判断磁盘 IO 瓶颈是否与内存相关
在调整参数前，先确认瓶颈是否来自内存不足。使用 SHOW GLOBAL STATUS 查看 Innodb_buffer_pool_read_requests 和 Innodb_buffer_pool_reads，前者是逻辑读次数，后者是物理读次数。若 Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests 的比例持续超过 1%，说明缓存命中率偏低，内存参数有优化空间。同时观察 SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'，若该值增长迅速，说明临时表频繁落盘，与 tmp_table_size 等参数相关。
核心参数调整：innodb_buffer_pool_size
这是 InnoDB 最重要的内存参数，决定了数据和索引缓存在内存中的大小。建议设置为服务器物理内存的 60%-80%，但需预留操作系统和其他进程的内存。例如，若服务器有 64GB 内存，可设置为 40GB 左右。修改后需重启 MySQL 或通过 SET GLOBAL innodb_buffer_pool_size = ... 动态调整（注意：动态调整需在 MySQL 5.7+ 且 innodb_buffer_pool_size 可动态设置）。调整后观察 Innodb_buffer_pool_reads 是否下降。
注意：若数据总量远大于内存，buffer pool 无法完全容纳，磁盘 IO 仍会存在，此时可考虑增加内存或使用其他优化手段。
针对 MyISAM 的 key_buffer_size
若仍在使用 MyISAM 表，key_buffer_size 决定索引块缓存大小。建议设置为内存的 25%-30%，但 MyISAM 已逐渐被 InnoDB 取代，若非必要不建议新项目使用。调整后可通过 SHOW GLOBAL STATUS LIKE 'Key_reads' 和 Key_read_requests 检查命中率。
减少临时表落盘的参数
排序和分组操作可能产生临时表，若临时表过大则会写入磁盘。调整 tmp_table_size 和 max_heap_table_size，两者取较小值作为内存临时表上限。例如，设置为 64MB，可减少磁盘临时表的产生。但注意，过大的值可能导致内存压力，需权衡。
其他相关参数与注意事项
innodb_log_buffer_size：控制事务日志缓冲区，可减少日志写入磁盘频率，但通常影响较小。innodb_flush_log_at_trx_commit：设置为 0 或 2 可减少磁盘同步，但会牺牲持久性，需根据业务权衡。innodb_io_capacity：控制 InnoDB 刷新脏页的 IO 能力，若磁盘较慢，可降低该值，避免 IO 风暴。
调整参数后，务必使用 SHOW VARIABLES 验证生效，并持续监控性能。注意，某些参数修改需要重启，动态修改可能不持久，需写入配置文件。
调优的失败条件与常见误区
若调整后磁盘 IO 未下降，可能原因：数据量远超内存、存在大量随机写入（如频繁更新）、或磁盘本身性能不足。常见误区包括：盲目将 buffer pool 设置为内存的 80% 以上，导致操作系统内存不足；忽略 innodb_flush_log_at_trx_commit 的持久性影响；未考虑不同存储引擎的差异。此外，MySQL 版本不同，参数默认值和行为可能有差异，建议参考官方文档。
参考资料
- Linux 内核文件系统文档 – 了解底层文件系统与 IO 行为，有助于理解磁盘 IO 的产生。
- GNU Parted 用户手册 – 磁盘分区相关，可作为磁盘布局优化的参考。
延伸阅读