数据库主机存储与文件系统选型
数据库主机存储与文件系统选型一、具体的问题
很多 DBA 在搭建数据库服务器时，把精力全花在数据库参数和 SQL 调优上，却忽略了最底层、也最致命的一环——存储与文件系统。等到线上出现"写入抖动""IO 打满""备份窗口不够"才回头补课，往往要停机换盘、迁移数据，代价极大。
一个真实场景：某业务库用 SATA 机械盘 + ext4 默认挂载，平时查询没问题，一到月底批量结算，磁盘 util 直接 100%，平均等待从 2ms 飙到 200ms，整个系统卡死。根因不是 SQL，是存储选型一开始就错了。
本文聚焦一个具体问题：数据库主机的存储（HDD/SSD/NVMe）和文件系统（ext4/xfs）该怎么选、挂载参数怎么配，才能避开这类坑。
二、核心原理
1. 存储介质决定 IO 上限
[*]HDD（机械盘）：随机 IO 能力极差，单盘 IOPS 通常只有 100~200，只适合冷数据、归档、备份仓库。
[*]SATA SSD：随机 IOPS 能到 1 万~3 万，性价比高，是多数 OLTP 库的主力。
[*]NVMe SSD：IOPS 可达 10 万~50 万，延迟 sub-ms，适合高并发、低延迟要求的交易库、缓存层。
关键指标看三个：IOPS（每秒 IO 次数）、吞吐量（MB/s）、延迟（ms）。数据库最怕随机小 IO（8K~16K）的延迟和 IOPS，不要被顺序读写的峰值带宽迷惑。
2. 阵列与条带提升并行度
单盘再快也有上限，用 RAID 把多块盘组合：
[*]RAID 10：镜像+条带，读性能和冗余都好，写有镜像开销，是数据库最稳妥的选择。
[*]RAID 5/6：靠校验提供冗余，写放大明显（读改写），且一块盘坏后重建期间性能骤降、风险高，不推荐给高写入库。
[*]条带大小（stripe size）：建议与数据库块大小对齐（如 64K~256K），减少跨盘读。
3. 文件系统：ext4 还是 xfs？
[*]ext4：成熟稳定，工具链丰富，但大文件、高并发场景下容易有锁竞争，fsck 在大磁盘上很慢。
[*]xfs：为高并发、大文件、大容量设计，延迟分配和分配组机制让它在大 IO 压力下表现更稳，是很多发行版（如 RHEL/CentOS）数据库服务器的默认推荐。
对数据库而言，xfs 通常是更稳的选择，尤其数据量大、并发高的场景。
4. 挂载参数直接影响性能与一致性
错误的挂载参数会让前面所有硬件投资打折扣：
[*]noatime：禁止记录文件访问时间，减少无谓写 IO（数据库几乎不需要 atime）。
[*]nodiratime：同上，针对目录。
[*]数据库有自己 WAL/redo 日志保证持久性，通常不需要文件系统的 barrier（但要确认底层存储有掉电保护电容的写缓存，否则有丢数据风险）。
[*]大内存库配合大页（hugepage）能减少 TLB miss。
三、实例参考（动手步骤）
下面给出一套可照做的排查与配置流程，在 Linux 数据库主机上验证存储与文件系统是否到位。
1) 先看磁盘介质与当前 IO 负载，定位瓶颈：
# 看磁盘列表与型号，ROTA=1 是机械盘，0 是 SSD/NVMe，一眼区分介质
lsblk -d -o NAME,SIZE,ROTA,TYPE,MODEL
# 实时看每个设备的 util / await / svctm
iostat -x 1
# 重点看 %util（是否接近 100%）、await（平均等待 ms）、r/s w/s（读写次数）
2) 格式化为 xfs 并合理挂载：
# 建 xfs（数据盘 /dev/sdb）
mkfs.xfs -f /dev/sdb
# 挂载：noatime 减少写放大；nobarrier 需确认存储有掉电保护
mount -o noatime,nodiratime /dev/sdb /data
# 写入 /etc/fstab 持久化
echo '/dev/sdb /data xfs noatime,nodiratime 0 0' >> /etc/fstab
3) 验证数据目录落在目标文件系统，且挂载参数生效：
# 看挂载选项，应为 ... type xfs (rw,noatime,nodiratime,...)
mount | grep /data
# 用 fio 压测随机写，对比选型前后
fio --name=randwrite --rw=randwrite --bs=8k --size=1G \
--numjobs=4 --runtime=60 --time_based --group_reporting
# 关注 IOPS 和 clat（完成延迟）百分位，数据库最看 P99 延迟
4) 前后对比：把"SATA SSD + ext4 默认"与"NVMe + xfs(noatime)"各跑一遍 fio，8k 随机写 IOPS 和 P99 延迟 会有数量级差异；再用 iostat -x 1 观察业务高峰时 %util 是否回落到安全区间（建议 <70%）。
四、实操检查清单
[*]介质是否匹配负载：OLTP 交易库优先 NVMe/企业级 SATA SSD，冷数据/备份才用 HDD？
[*]是否用 RAID 10 而非 RAID 5/6 承载高写入库？单盘故障重建风险是否评估过？
[*]文件系统是否选 xfs（大库/高并发），挂载是否带 noatime,nodiratime？
[*]是否用 lsblk -d -o NAME,ROTA 确认介质，而非凭"以为"？
[*]是否用 iostat -x 1 和 fio 实测过 IOPS 与 P99 延迟，而非只看厂商标称带宽？
[*]存储是否有掉电保护的写缓存？没有的话 nobarrier 会丢数据，务必谨慎。
[*]备份盘是否独立、是否与主库 IO 隔离，避免备份把主库 IO 也拖垮？
页:
[1]