innodb_io_capacity应设为磁盘70%负载下的随机写IOPS，SATA盘通常100–180；该值仅影响脏页刷新，设错会导致buffer_pool_wait_free飙升或dirty pages堆积。
MySQL 的 innodb_io_capacity 怎么设才不拖慢 SATA 盘
设太高会让 SATA 盘持续满负载，IO 等待飙升；设太低又压不住 SSD 的吞吐。关键不是“推荐值”，而是看你的盘实际能稳住多少 IOPS。
-
innodb_io_capacity应设为盘在 70% 持续负载下的随机写 IOPS（非顺序读），SATA 机械盘通常 100–180，别硬套文档写的 200 - 用
fio实测：fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=16k --direct=1 --numjobs=4 --runtime=60 --time_based --group_reporting，取iops列平均值 × 0.7 - 该值只影响脏页刷新节奏，不影响查询响应；但设错会导致
Innodb_buffer_pool_wait_free飙升或Dirty pages堆积
SSD 上要不要开 innodb_flush_method=O_DIRECT
要，但得确认文件系统和内核支持；开了能绕过 page cache，避免双缓存放大写放大，对 NVMe 尤其明显。
- Linux 2.6.32+ + ext4/xfs 下
O_DIRECT安全可用；老内核或 btrfs 可能触发Invalid argument错误 - 如果用 LVM 或加密卷（如 dm-crypt），
O_DIRECT可能失效，此时O_DSYNC更稳，但写延迟略高 - 实测发现：SSD 上
O_DIRECT比默认fsync模式降低 15–30% 的innodb_log_waits，尤其在高并发 insert 场景
同一个 MySQL 实例混用 SATA 和 SSD 表空间？
可以，但必须手动隔离——InnoDB 不会自动识别介质差异，所有表空间共享同一套 IO 调度策略。
- 把热数据表（如订单、用户）的
.ibd放 SSD 路径，冷数据表（如日志归档）放 SATA 路径，通过CREATE TABLE ... DATA DIRECTORY='/ssd/mysql/'控制 - 务必关闭
innodb_file_per_table=OFF，否则系统表空间（ibdata1）仍在原路径，且无法拆分介质 - 注意
mysqldump和mysqlpump默认不备份DATA DIRECTORY路径，恢复时容易漏表，需显式加--tab或用xtrabackup --stream
为什么调整了 io_capacity 却没改善写入延迟？
因为 innodb_io_capacity 只管后台刷脏页，不管 redo log 写入；真正卡写入的往往是 innodb_log_file_size 和磁盘 fsync 延迟。
- 先查
SHOW ENGINE INNODB STATUS\G里Log sequence number和Last checkpoint at差值，超 1GB 就说明 log 太小，频繁 checkpoint - SATA 盘建议
innodb_log_file_size≥ 512M，SSD 可到 1G–2G；改之前必须停库、删旧 log、重启 - 用
iostat -x 1观察%util和await：若await > 20ms且%util ≈ 100%，说明是硬件瓶颈，调参数没用
介质适配最易被忽略的一点：buffer pool 大小不能只看内存余量，而要看介质延迟——SATA 上过大的 buffer pool 会导致 flush 压力集中爆发，反而加剧 IO 波动。
