IO 和内存是数据库性能最底层的两块基石。内存不够，缓冲池命中率下降，磁盘 IO 暴涨；IO 配置不当，再快的内存也得干等磁盘。这一节聚焦实际调优中需要关注的配置项，帮你把硬件资源用在刀刃上。
21.4.1 内存分配的关键原则
MySQL 的内存使用可以粗分为全局内存和会话内存两大类。
- 全局内存：所有连接共享，主要是 InnoDB 缓冲池（
innodb_buffer_pool_size），还包括 InnoDB 日志缓冲（innodb_log_buffer_size）、表定义缓存（table_definition_cache）、表打开缓存（table_open_cache）等。 - 会话内存：每个连接独占，包括排序缓冲（
sort_buffer_size）、连接缓冲（join_buffer_size）、读缓冲（read_buffer_size）、临时表（tmp_table_size、max_heap_table_size）等。这些参数不要设得太大，因为它们是按需分配且可能累积，连接数一高内存立刻爆掉。
最重要的内存参数：innodb_buffer_pool_size
这是 MySQL 中价值最高的内存参数。缓冲池缓存数据页和索引页，直接决定读性能。一般建议：
- 对于专用数据库服务器，设置为物理内存的 60% ~ 80%。例如 64GB 内存的机器，可以设 40GB ~ 50GB。
- 如果服务器还跑着其他服务，适当降低比例，但要确保操作系统和文件系统缓存也有一定余量。
- 8.0 支持在线动态调整（
SET GLOBAL innodb_buffer_pool_size = ...），但大幅调整时仍需谨慎，后台的重新分配需要时间。
实例估算：你可以在运行时通过 SHOW ENGINE INNODB STATUS 中的 BUFFER POOL AND MEMORY 段观察命中率，稳定运行后 Buffer pool hit rate 应该接近 100%（99% 以上）。如果低于 95%，增大缓冲池通常是最有效的优化手段。
会话级内存参数：小而精
sort_buffer_size：用于排序操作的内存，默认 256KB。如果有很多带排序的大查询，可以适当调到 1~4MB，但绝不可过大。注意：一个会话可能同时用多个排序缓冲，乘积效应明显。join_buffer_size：用于无索引关联的缓冲区，默认 256KB。同样不要盲目增大，优化关联查询的正确方向是给驱动表加索引，而不是靠增大缓冲区。tmp_table_size和max_heap_table_size：控制内存临时表的最大尺寸，超过后会转成磁盘临时表（在 tmpdir 目录）。这两个参数取小值，如 16~64MB，避免单个查询撑爆内存。
防止 OOM 的实用规则：给 MySQL 的总可用内存留出约 20% 的余量给操作系统和文件系统缓存，而且最好启用 vm.overcommit_memory = 2（配合 vm.overcommit_ratio）来限制过度的内存分配。MySQL 8.0 自带的性能视图 sys.memory_by_user_by_current_bytes 也可以辅助定位内存消耗大户。
21.4.2 IO 配置优化：让磁盘跑得更快
MySQL 的 IO 主要来自数据文件的读写、日志文件的顺序写、临时文件的读写等。调优方向是：避免不必要的 IO、合并 IO 操作、匹配底层存储特性。
关键参数 innodb_io_capacity 和 innodb_io_capacity_max
这两个参数告诉 InnoDB 磁盘每秒可以处理多少 IO 操作（IOPS），直接影响后台刷新脏页和合并写操作的速率。默认值很低（200~400），适合老式 HDD。如果你用的是 SSD，一定要调大：
- 对于普通 SSD（几千 IOPS），可设
innodb_io_capacity = 2000，innodb_io_capacity_max = 4000或更高。 - 对于高性能 NVMe SSD（上万 IOPS），可设
innodb_io_capacity = 5000~10000，innodb_io_capacity_max适当翻倍。 - 不调整的后果：DB 会以为自己在一个很慢的磁盘上，脏页刷新小心翼翼，写压力稍大就可能出现性能抖动甚至写入停滞。
日志刷新策略 innodb_flush_method
这个参数决定 InnoDB 如何处理数据文件和日志文件的写回方式，影响刷页效率。
- Linux 下推荐
O_DIRECT：数据文件使用直接 IO，绕过操作系统缓存，防止双重缓存（Buffered IO + Buffer Pool）浪费内存。Redo 日志文件通常用O_DSYNC或fsync（由innodb_flush_log_at_trx_commit控制）。 - 如果使用磁盘阵列或 SAN，某些存储缓存需要 OS buffer，此时可能选
O_DSYNC之类的组合，但绝大多数标准 SSD/HDD 环境，O_DIRECT是最稳妥的。 - 在 MySQL 8.0 中，
innodb_flush_method还增加了O_DIRECT_NO_FSYNC等选项以优化性能，需要测试后启用。
脏页刷新与写压力控制
innodb_max_dirty_pages_pct：缓冲池中脏页的最大比例，默认 90%。通常不需要调小，因为 InnoDB 已有自适应的刷新算法。如果写负载非常高且要求低延迟，可以适当降低（比如 75%），让后台更积极地刷盘。innodb_flush_neighbors：控制刷新一个脏页时是否顺便刷新相邻脏页。传统 HDD 机械盘建议开启（值为 1）以合并 IO；对于 SSD，随机 IO 成本低，建议关闭（值为 0），避免不必要的写入放大。innodb_lru_scan_depth：影响页清理线程每秒扫描 LRU 列表的深度，间接决定刷新速度。如果看到InnoDB: page_cleaner相关警告，可以适度增大（默认 1024），SSD 下可调到 4000~8000。
减少 IO 的实用技巧
- 适当扩大 Redo Log 文件：两个重做日志文件的总大小（
innodb_redo_log_capacity或旧版的innodb_log_file_size * innodb_log_files_in_group）如果太小，会导致频繁的检查点和日志切换，引发大量的脏页刷新 IO。8.0 中建议设置innodb_redo_log_capacity为 1~2GB，甚至更高。 - 合理配置临时表目录：
tmpdir可以指定到独立的快速磁盘（如 SSD）上，分散临时文件创建的 IO 压力。如果内存够大，尽量让临时表留在内存中（调优 MySQL 的临时表参数组合）。 - 开启异步 IO：
innodb_use_native_aio默认开启，可以提交多个 IO 请求而不必等待单个完成，提升吞吐量。不要随意关闭。
21.4.3 操作系统层面的配合
- I/O 调度算法：对于 SSD，通常使用
noop或deadline调度器（内核 ≥ 5.x 后可能统一为mq-deadline），减少不必要的合并和排序。可以通过echo mq-deadline > /sys/block/sda/queue/scheduler设置。 - 文件系统选择：XFS 是 Linux 上跑 MySQL 的首选，对并发高负载和大型文件处理表现较好；ext4 也可以接受，但需要注意日志模式（建议
data=writeback，同时搭配电池备份的 RAID 卡或服务器不掉电环境）。切忌使用不支持O_DIRECT的文件系统。 - swap 与内存管理：生产数据库服务器应当尽可能禁用 swap 或使 swap 仅用于紧急情况。设置
vm.swappiness = 1或0，命令内核尽量不换出内存页。一旦 InnoDB 缓冲池被 swap，性能会断崖式下跌。 - 透明大页（Transparent Huge Pages）：建议关闭。THP 在数据库场景下容易导致内存碎片和严重的延迟抖动。可以通过
echo never > /sys/kernel/mm/transparent_hugepage/enabled永久关闭。
21.4.4 调优闭环：观察、调整、验证
没有一个配置是放之四海而皆准的，必须根据实际监控数据迭代调整。
- 内存监控：使用
free -h观察系统内存使用，用SHOW ENGINE INNODB STATUS看 Buffer Pool 命中率，sys.memory_global_total看 MySQL 层面内存分配。 - IO 监控：
iostat -x 1观察磁盘的 await、r/s、w/s、%util。如果 %util 持续接近 100%，说明磁盘已饱和，需要升级硬件或优化 SQL/索引。 - 慢日志与性能视图：
performance_schema中的文件 IO 摘要表（file_summary_by_instance）可以定位到具体哪一个表空间或日志文件产生了大量 IO，再有针对性地处理。
最后提醒一个容易忽略的点：很多时候我们看到磁盘 IO 飙升，第一反应是调 IO 参数，可实际根源是 SQL 消耗了大量物理读（索引缺失或设计不当）。请在确认 SQL 和索引已经优化的前提下，再做深度的 IO 与内存参数调优，这样才事半功倍。