raid 10 是裸金属上 mysql 写入性能优化最直接有效的硬件层手段，但必须配合带 bbu/fbwc 的企业级 raid 卡、企业级 ssd（含 plp）、innodb_flush_log_at_trx_commit=2 等软硬协同配置，缺一不可。
RAID 10 是裸金属上 MySQL 写入性能优化最直接有效的硬件层手段，但必须配合控制器缓存策略、SSD选型和 MySQL 日志参数协同生效，单靠“做了 RAID 10”几乎不提升写入速度。
RAID 10 阵列必须用带 BBU/FBWC 的企业级 RAID 卡
消费级主板软 RAID 或廉价 RAID 卡（如 LSI 9207-8i 无缓存版）无法发挥 RAID 10 的写入优势。原因在于：没有电池/闪存保护的写缓存（Write-Back）会被控制器强制降级为 Write-Through 模式，此时每次 INSERT 都要等物理写完成，IOPS 跌回单盘水平。
- 必须确认 RAID 卡支持
Write-Back且BBU或FBWC状态正常（可用arcconf getconfig 1 battery或MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL检查） - 禁用
CacheCade或读缓存加速功能——MySQL 写密集场景下，读缓存收益极低，反而挤占写缓存空间 - 避免使用 IT 模式（Initiator Target）的 HBA 卡模拟 RAID，它不提供任何写缓存能力
SSD 必须选企业级并关闭非持久化写缓存
消费级 NVMe SSD（如 Samsung 980 Pro）虽快，但断电后易丢数据，RAID 卡的 Write-Back 缓存会放大该风险；而企业级 SSD（如 Intel D5-P5316、Solidigm D5-P5430）内置 PLP（Power Loss Protection）电容，可保障缓存数据落盘。
- 若误用消费级 SSD，必须执行
hdparm -W 0 /dev/nvme0n1关闭设备级写缓存，否则与 RAID 卡缓存叠加会导致双重丢失风险 - 不要依赖
nvme set-feature -f 0x08 -v 0关闭 volatile write cache——部分固件不响应，应以厂商文档为准 - RAID 10 下 SSD 数量建议为 4 的倍数（如 4/8/12 块），避免条带不对齐导致部分盘空转
MySQL 必须调低日志刷盘频率才能释放 RAID 10 写吞吐
即使 RAID 10 吞吐再高，innodb_flush_log_at_trx_commit=1 仍会让每个事务卡在磁盘 IO 上，把硬件优势锁死。这是最容易被忽略的软件层瓶颈。
- 非金融/强一致性业务，设为
innodb_flush_log_at_trx_commit=2：日志写入 OS page cache，由内核每秒刷一次，写延迟从毫秒级降至微秒级 - 同步 binlog 时需配套设
sync_binlog=1000或sync_binlog=0，避免 binlog 刷盘成为新瓶颈 - 增大
innodb_log_file_size至 1G（如innodb_log_file_size=1073741824），减少 checkpoint 触发频率，降低脏页批量刷盘压力
磁盘调度器和文件系统必须匹配 SSD 特性
Linux 默认的 cfq 或 bfq 调度器是为 HDD 设计的，会对 SSD 引入额外延迟；EXT4 默认启用 barrier=1 也会抑制写缓存效果。
- 将调度器切为
none（NVMe）或deadline（SATA SSD）：echo none > /sys/block/nvme0n1/queue/scheduler - 挂载 EXT4 时加
noatime,nobarrier,discard参数：mount -o noatime,nobarrier,discard /dev/md0 /var/lib/mysql - 禁用 swap：
swapoff -a并注释/etc/fstab中 swap 行，避免内存压力下触发 swap IO 干扰数据库写入
真正决定 RAID 10 对 MySQL 写入是否有效的，不是阵列本身，而是从 NAND 闪存断电保护、RAID 控制器缓存策略、到 MySQL 日志提交语义这三层之间能否形成可信的数据落盘链路。任何一个环节降级（比如用了消费级 SSD 却没关写缓存，或 RAID 卡 BBU 失效却仍开 Write-Back），都会让整套优化失效，甚至比单盘更不可靠。
