在我们运营的一套核心账务系统中，MySQL 日均处理超 7 千万行写入，QPS 平均维持在 12K，峰值 TPS 一度突破 8000。在这种高并发写入场景下，即便表结构与SQL逻辑已经优化到极致，最终瓶颈还是回到了存储层的随机写 IOPS 与 fsync latency 上。最初我们使用的是常规企业级 SATA SSD + RAID1 镜像盘，结果 InnoDB fsync() 常态在 3~5ms，TPS 上限卡死在 5500 左右，CPU 明明还有余量，但 TPS 提不上去。
直到我们启用了Intel D7-P5520 NVMe U.2 SSD 组成的 RAID10 阵列，并重构了 IO 调度与文件系统参数，MySQL TPS 峰值才真正突破 10K，而且 fsync latency 被压缩到 300us 以内。以下是我完整的部署与调优过程，供遇到同类问题的工程师参考。
一、架构背景与瓶颈定位
1.1 初始部署架构
- 地域节点：香港荃湾BGP多线机房
- 服务器配置：2×Intel Xeon Gold 6346 + 512GB DDR4 + 6×2TB SATA SSD（RAID1+hotspare）
- MySQL版本：Percona Server 8.0.36
- 业务特性：大量金融交易明细写入，主键自增，ACID全启用（innodb_flush_log_at_trx_commit=1）
1.2 瓶颈分析过程
我们使用以下工具排查瓶颈：
- iostat -x 1：观察 SSD 的 svctm 和 %util
- SHOW ENGINE INNODB STATUS\G：查看 fsync 次数和平均耗时
- perf record + perf report：确认 CPU 未打满，系统热点主要在 os_file_write() 与 pwrite()
- dstat –disk –fsync：持续监控 fsync QPS 与耗时
结论明确：TPS 无法提升的根源在于 SSD 写入延迟高 + fsync QPS 饱和，RAID1 性能天花板低，成为当前 MySQL TPS 的主要限制因素。
二、方案设计：RAID10 + Intel D7 NVMe 重构存储IO栈
2.1 选型思路
我们选择了Intel D7-P5520 U.2 NVMe 作为核心存储介质，理由如下：
| 项目 | 规格参数 |
|---|---|
| 接口 | PCIe 4.0 x4 (U.2) |
| 读写IOPS | 高达 970K/260K |
| 顺序吞吐 | 7GB/s 读取，4.2GB/s 写入 |
| 延迟 | 典型写延迟 < 20μs |
| 耐久性 | DWPD ≥ 1.3，保障金融类写入场景稳定性 |
| 兼容性 | 支持 Smart Array + Linux mdadm 组合部署 |
2.2 硬件部署与RAID阵列构建
- 控制器：Liqid x16 PCIe Switch 卡（支持多块U.2并发直通）
- NVMe设备：共4块Intel D7-P5520，配置为 RAID10，保障性能与冗余
- 工具：Linux原生 mdadm 工具组建RAID10
mdadm --create /dev/md10 --level=10 --raid-devices=4 /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1
mkfs.ext4 -E stride=128,stripe-width=256 -O extent,uninit_bg,dir_index /dev/md10
mount -o noatime,nodiratime,barrier=0 /dev/md10 /data/mysql
注意事项：
- stride 与 stripe-width 参数需与 RAID10 chunk size 对齐（假设 chunk=128K）
- barrier=0 需要搭配掉电保护 SSD，否则存在数据一致性风险
- RAID10 组合确保了在 2盘任意故障的情况下数据安全
三、MySQL 层参数优化：压榨 IO 性能上限
3.1 文件系统挂载与IO调度器设置
# 关闭 CFS 调度干扰
echo none > /sys/block/md10/queue/scheduler
# 启用 IO 多队列优化
echo 0 > /sys/block/md10/queue/nomerges
echo 128 > /sys/block/md10/queue/nr_requests
3.2 MySQL 核心参数调整
innodb_flush_log_at_trx_commit = 1 # 强一致性写入
innodb_io_capacity = 80000 # 根据测试IOPS极限设置
innodb_io_capacity_max = 160000
innodb_flush_method = O_DIRECT # 避免 page cache 二次写放大
innodb_log_file_size = 2G # 扩大 redo buffer，减少写频率
innodb_buffer_pool_size = 320G # 尽量避免频繁磁盘访问
3.3 RAID10 环境下 fsync 延迟实测
| 测试指标 | RAID1 (SATA SSD) | RAID10 (Intel D7 NVMe) |
|---|---|---|
| 单次 fsync 延迟 | 4.2ms | 270μs |
| TPS 峰值 | 5400 | 10600 |
| InnoDB log write time | ~3.9ms | < 0.4ms |
| CPU idle ratio | 55% | 33%（资源利用率提高） |
四、压力测试与稳定性验证
4.1 测试工具：Sysbench 场景模拟
sysbench oltp_write_only.lua \
--mysql-host=127.0.0.1 --mysql-user=root \
--tables=16 --table-size=1000000 \
--threads=64 --time=300 \
--report-interval=5 \
run
结果表现：
- TPS 稳定在 10K~10.5K，无明显波动
- InnoDB redo log flush latency 明显下降
- RAID10 写性能对 fsync 并发支撑能力显著优于 RAID1
4.2 持续稳定运行
连续运行72小时压测，SSD温度 < 50°C，无掉盘或坏块
dmesg、smartctl 监控无异常
业务写入无丢包，binlog relay 稳定复制无延迟
五、IO不是问题，前提是你选对了硬件
在 MySQL 的 TPS 提升路径上，优化 SQL 与索引只是第一步，真正决定上限的往往是 硬件 IOPS 与 fsync latency 的瓶颈。而我们在香港部署环境中，通过Intel D7 NVMe + RAID10 + EXT4 调优的组合，成功将写入延迟压缩到了亚毫秒级，为上层业务带来了超过 90% 的 TPS 提升。
如果你也正遭遇类似“CPU还有余力但TPS上不去”的情况，不妨深入看看你的 IO 栈，真正的瓶颈，可能藏在那一块“快不起来的SSD”里。
如需深入探讨 RAID10 + NVMe 架构在金融、跨境电商等高写入场景下的性能表现，欢迎留言交流或查看后续的 binlog sync 分布式容灾架构实战笔记。
