MySQL 场景专项 FIO 压测案例

数据库尤其是 MySQL（InnoDB 引擎）对 磁盘 IO 的依赖极强。
它的典型特点是：

• • 4KB 随机读写（对应 InnoDB 页大小）
• • 高并发小 IO（事务并发提交）
• • WAL（redo log）顺序写 + 数据页随机读写

因此，如果要用 fio 模拟 MySQL 的场景，可以这样测试：

1️⃣ 随机 4KB 读写（核心场景）

fio --name=mysql-randrw \
    --filename=/data/mysql_testfile \
    --size=2G \
    --bs=4k \
    --rw=randrw \
    --rwmixread=70 \
    --ioengine=libaio \
    --iodepth=64 \
    --numjobs=8 \
    --runtime=300 \
    --time_based \
    --direct=1 \
    --group_reporting

参数说明：

• • --bs=4k ：块大小 4KB，模拟 InnoDB 页
• • --rw=randrw ：随机读写混合
• • --rwmixread=70 ：读占 70%，写占 30%，符合大多数 MySQL 读多写少的场景
• • --iodepth=64 ：队列深度，模拟并发事务
• • --numjobs=8 ：并发 8 个线程，模拟多连接访问
• • --runtime=300 --time_based ：持续跑 5 分钟，避免短时间波动

2️⃣ redo log 顺序写（事务提交场景）

fio --name=mysql-redolog \
    --filename=/data/mysql_redolog \
    --size=1G \
    --bs=512 \
    --rw=write \
    --ioengine=libaio \
    --iodepth=1 \
    --numjobs=4 \
    --runtime=300 \
    --time_based \
    --direct=1 \
    --group_reporting

参数说明：

• • --bs=512 ：InnoDB redo log 写入是 512B 对齐
• • --rw=write ：顺序写，模拟事务提交写日志
• • --iodepth=1 ：redo log 写入是低并发、顺序刷盘
• • --numjobs=4 ：多个线程模拟不同事务提交

3️⃣ 结果怎么看？

重点关注这几个指标：

• • IOPS：代表数据库在这种场景下能支撑多少事务/查询
• • clat（完成延迟）：如果 > 10ms，数据库事务延迟会显著增加
• • util=100%：表示磁盘被打满，业务再多 IO 也不会提升

4️⃣ 对 DBA 的意义

• • 如果 随机 4KB IOPS < 5000，SSD 都不算合格，更别提跑数据库了。
• • redo log 顺序写延迟太高，会导致 事务提交卡顿，影响整体 TPS。
• • 通过 fio，你能 量化存储极限，做到心里有数，再决定是优化 SQL、调参，还是换存储。

📢 一句话总结：
用 fio 跑 MySQL 专属场景，可以提前知道数据库瓶颈，避免“数据库背锅”，而是精准判断问题出在存储还是 SQL！