6.2 存储硬件与配置

本节摘要：存储是数据库最大瓶颈——磁盘慢。本节讲清楚 HDD/SSD/NVMe 选型、RAID 配置、IO 调度、文件系统，让存储匹配数据库需求。

存储对数据库的影响

数据库是 IO 密集型——读数据、写日志、刷脏页。存储决定 IO 性能：

IOPS（每秒 IO 次数）——随机读写能力。
吞吐（MB/s）——顺序读写能力。
延迟（ms）——单次 IO 响应时间。

不同负载需求：

OLTP——随机 IO 多（点查询、更新），要高 IOPS 低延迟。
OLAP——顺序 IO 多（大扫描），要高吞吐。

存储介质选型

HDD（机械硬盘）：

IOPS 低（100-200），延迟高（5-10ms）。
吞吐中等（100-200MB/s）。
容量大便宜——冷数据/归档。
不适合热数据库——慢。

SATA SSD：

IOPS 高（数万-十万），延迟低（0.1-1ms）。
吞吐中等（500MB/s）。
性价比好——多数数据库。
适合 OLTP/OLAP。

NVMe SSD：

IOPS 极高（十万-百万），延迟极低（<0.1ms）。
吞吐高（2-7GB/s）。
性能最好——高性能数据库。
适合高并发低延迟。

选择：

热数据库——NVMe SSD（最佳）或 SATA SSD。
冷数据/归档——HDD。
预算有限——SATA SSD。
云——选 SSD/NVMe 实例类型。

RAID 配置

RAID：多盘组合提性能/冗余。

RAID 0：条带，无冗余。最快但盘坏丢数据。不推荐生产。

RAID 1：镜像，两盘互备。冗余好，读快，写慢。适合日志盘（redo/binlog）。

RAID 10：条带+镜像（RAID 1+0）。性能+冗余好，容量 50%。推荐数据库（数据盘）。

RAID 5：条带+奇偶校验。容量 75-87%，写慢（算校验）。不推荐数据库（写性能差、重建风险）。

RAID 6：双校验。容量 67-83%，更安全但写更慢。冷数据可选。

IO 调度器

Linux IO 调度器决定 IO 顺序：

CFQ（Completely Fair Queuing）：

公平分配 IO——适合桌面多任务。
数据库不推荐——延迟高。

Deadline：

IO 超时机制——防止饿死。
适合数据库——延迟可控。

NOOP：

简单 FIFO——无调度。
适合 SSD/NVMe（无寻道，不需调度）。

MQ-DEADLINE/NONE/KYBER（多队列，现代内核）：

NVMe 多队列优化。
推荐 NVMe 用 NONE/MQ-DEADLINE。

配置：


# 查看当前调度器
cat /sys/block/sdX/queue/scheduler
# 设置（SSD/NVMe）
echo none > /sys/block/nvme0n1/queue/scheduler

文件系统

ext4：

主流，稳定，日志。
适合多数数据库。
mount 选项：noatime（不更新访问时间，减 IO）、nodiratime。

XFS：

高性能，大文件优。
适合大数据库。
mount 选项：noatime。

ZFS：

高级文件系统——校验、压缩、快照、ARC 缓存。
适合数据库（特别 PG/ZFS 组合）。
注意：ARC 和数据库缓冲池冲突，要调 ARC 上限。

Btrfs：

类似 ZFS，但稳定性不如 ZFS。
数据库慎用。

IO 配置优化

1. 预读

OS 预读——顺序扫描提性能。
blockdev --setra——调预读块数。
SSD 预读可小（随机多），HDD 预读大（顺序）。

2. 队列深度

NVMe 多队列——并发 IO。
/sys/block/nvmeX/queue/nr_requests——调队列深度。

3. IO 优先级

ionice——设 IO 优先级。
数据库高优先级，备份低优先级。

4. 透明大页（THP）

数据库通常禁用 THP——可能导致延迟突刺。
echo never > /sys/kernel/mm/transparent_hugepage/enabled。

5. 文件句柄

数据库打开多文件——调高文件句柄。
ulimit -n / /etc/security/limits.conf——nofile 65535+。

IO 监控

iostat -x：

%util——磁盘利用率（接近 100% 瓶颈）。
await——IO 等待时间（SSD <10ms，HDD <20ms）。
avgqu-sz——队列长度（高则排队）。
r/s w/s——读写 IOPS。
rkB/s wkB/s——读写吞吐。

iotop：

按进程 IO——找 IO 大的进程。

数据库 IO：

show engine innodb status——InnoDB IO 状态。
pg_stat_io（PG 16+）——IO 统计。

⚠️ 常见误读：以为"RAID 5 容量省适合数据库"。RAID 5 写慢（算校验）、重建风险（大盘重建时间长可能二次故障）。数据库用 RAID 10（性能+冗余），日志用 RAID 1。

💡 关键直觉：存储是数据库最大瓶颈（IO 密集读数据/写日志/刷脏页）。指标 IOPS（随机）、吞吐（顺序）、延迟。介质——HDD（IOPS 100-200 延迟 5-10ms 容量大便宜冷数据）、SATA SSD（IOPS 数万-十万 0.1-1ms 性价比多数 DB）、NVMe SSD（IOPS 十万-百万 <0.1ms 2-7GB/s 最佳高性能）。RAID——0 条带无冗余不推荐、1 镜像日志盘、10 条带+镜像数据盘推荐（性能+冗余容量 50%）、5/6 校验写慢不推荐 DB。硬件 RAID 卡电池/超级电容保护写缓存 BBWC/FBWC 提写性能，HBA 直通 NVMe。IO 调度——CFQ 桌面不推荐 DB、Deadline 适合 DB 延迟可控、NOOP/NONE/MQ-DEADLINE NVMe 无寻道不需调度。文件系统——ext4/XFS 主流 noatime nodiratime 减 IO、ZFS 高级校验压缩快照 ARC（调 ARC 上限避冲突）、Btrfs 稳定性慎用。配置——预读（SSD 小 HDD 大）、队列深度 NVMe 多队列、IO 优先级 ionice、THP 禁用防延迟突刺、文件句柄 nofile 65535+。监控 iostat -x（%util 接近 100% 瓶颈/await SSD <10ms/avgqu-sz 队列/r/s w/s IOPS）、iotop 按进程、show engine innodb status/pg_stat_io。

本节要点回顾

存储影响：数据库 IO 密集（读数据/写日志/刷脏页），存储决定 IO 性能——IOPS（随机读写）、吞吐（顺序读写）、延迟（单次响应）。OLTP 随机多要高 IOPS 低延迟，OLAP 顺序多要高吞吐。
介质选型：HDD（IOPS 100-200 延迟 5-10ms 吞吐 100-200MB/s 容量大便宜冷数据归档不适合热 DB）、SATA SSD（IOPS 数万-十万 0.1-1ms 500MB/s 性价比多数 DB）、NVMe SSD（IOPS 十万-百万 <0.1ms 2-7GB/s 最佳高并发低延迟）。热 DB NVMe/SATA SSD，冷 HDD，云选 SSD/NVMe 实例。
RAID：0 条带无冗余不推荐、1 镜像两盘互备读快写慢适合日志盘 redo/binlog、10 条带+镜像性能+冗余容量 50% 推荐数据盘、5/6 校验写慢算校验重建风险不推荐 DB。硬件 RAID 卡电池/超级电容保护写缓存 BBWC/FBWC 提写性能，HBA 直通 NVMe 软件 RAID/ZFS。
IO 调度：CFQ 桌面公平 DB 不推荐延迟高、Deadline IO 超时防饿死适合 DB 延迟可控、NOOP FIFO 无调度适合 SSD/NVMe 无寻道、MQ-DEADLINE/NONE/KYBER 多队列 NVMe 推荐。echo none > /sys/block/nvme0n1/queue/scheduler。
文件系统：ext4 主流稳定日志 noatime nodiratime、XFS 高性能大文件优 noatime、ZFS 高级校验压缩快照 ARC（调 ARC 上限避数据库缓冲池冲突）、Btrfs 稳定性慎用。通用 ext4/XFS，高级 ZFS。mount noatime 减 IO。
配置优化：预读（blockdev --setra，SSD 小随机多 HDD 大顺序）、队列深度（NVMe 多队列 nr_requests）、IO 优先级（ionice DB 高备份低）、THP 禁用（echo never 防延迟突刺）、文件句柄（ulimit -n nofile 65535+ DB 打开多文件）。
监控：iostat -x（%util 接近 100% 瓶颈、await SSD <10ms HDD <20ms、avgqu-sz 队列高排队、r/s w/s IOPS、rkB/s wkB/s 吞吐）、iotop 按进程 IO 找大户、show engine innodb status InnoDB IO、pg_stat_io PG 16+ IO 统计。

IO 路径的逐环节优化清单

存储配置的本质是把 IO 路径上的每个环节都调到匹配数据库的负载特征，给一份逐环节清单。介质层：写密集的日志与数据文件放独立介质（日志的顺序写特性与数据的随机读特征对介质的要求不同），热数据与冷数据分层存放；持久内存或高速缓存盘做写缓冲时，必须确认掉电保护——没有保护的写缓存是数据完整性赌局。队列与调度层：IO 调度器按介质选择（机械盘用排序合并、固态盘用简单队列——把顺序化优化用在闪存上是浪费 CPU），队列深度调到能驱动设备满吞吐但不至于延迟堆积。多路径层：多路径策略与故障切换演练——链路冗余不演练等于没有，切换瞬间的 IO 停顿会触发数据库的误判（磁盘超时、主从切换），这个连锁反应值得在演练里预演一遍。文件系统层：挂载参数禁用访问时间更新、日志模式与数据库的写入模式匹配。每个环节的单项收益可能只有几个点，但 IO 路径是乘法链——五个环节各九折，整体就只剩六成；逐环节排查的价值正在于此，也是本章"最后物理层"的工程含义。

存储层的容量与性能双预算

存储配置的收官把"容量预算"与"性能预算"并列讲——多数团队只做了前者。容量预算：裸数据量加索引放大（一点五到三倍）加临时空间（排序与重建的峰值需求）加冗余（镜像或纠删），再乘增长年限——这是空间的账。性能预算：业务峰值 IO 需求（读写每秒数、带宽）对照设备供给能力（考虑阵列惩罚——镜像写放大、校验计算的读写放大），留三成余量——这是时间的账。双预算的意义在于拆穿一个常见幻觉："容量还够用"——空间够但性能早就到顶的系统比比皆是（慢不是因为装不下，是因为转不动）；反之也有"空间先到顶"的场景（大字段膨胀）。采购决策的正确姿势是两本账一起算、短板先补、同步增长。存储是数据库里最贵的耗材，双预算管理是让每一分采购费都花在真实的短板上——这既是技术功力，也是对预算的尊重。

存储层的故障演练剧本

存储章收官给一份故障演练剧本——冗余配置只有演练过才算数。场景一，单盘故障：拔盘（或模拟标记故障），观察告警时效、路径切换的 IO 停顿、业务层有无误判（磁盘超时报错）——恢复插入后数据一致性与重建过程。场景二，控制器切换：主控下电，观察切换时长与多路径的重连行为——数据库的 IO 超时要大于切换时长，这个配置关系在演练里验证。场景三，带宽打满：制造备份流量洪峰，观察协议心跳与复制延迟的表现——验证第 6 小节讲的流量隔离是否真的生效。场景四，慢盘退化：注入延迟（盘将死的典型形态），观察系统能否发现"性能退化"而不只是"硬故障"——慢盘是最难发现的隐患，演练它的价值最高。四个剧本每年一轮，存储层的冗余投资才算兑现——没有剧本的冗余是装饰品，出事时它只保证"看起来很安全地丢失"。

存储的交接清单

存储章收官给一份交接清单——存储管理员换人或接手新系统时的核对项。硬件侧：设备型号与固件版本、阵列与多路径配置、掉电保护状态、健康指示（SMART 与厂商工具的读数）。性能侧：双预算台账（容量与性能的最近一次核算）、基准测试记录（新机上线时的实测数据，作为日后退化的对照）、监控阈值与历史告警。流程侧：故障演练的上次时间与剧本、备件与厂商联系路径、变更窗口的惯例。这份清单的每行都对应本教程的一个知识点——它其实是存储章的目录变体，也是所有章节的共同归宿：知识最终要落成可交接的资产。系统的寿命长过任何工程师的任期，交接清单就是你和继任者隔空击掌的方式——他接手时的顺畅程度，就是你专业精神的最终评分。

收尾一句：存储层的所有配置优化，最终都指向同一个目标——"让 IO 路径的每一环都知道自己该多快"；预算、基准、演练三件套把这个目标变成可管理的日常，缺了任何一件，存储就退回到"黑箱加祈祷"的原始状态——而生产数据库经不起祈祷。

补一个云环境的特别提醒：云盘的性能与容量常是绑定的（按容量给 IOPS 与带宽档位），"加容量顺便加性能"与"想加性能必须加容量"两种绑定方向都存在——云上存储调优的第一课是读懂自家云的计费与性能模型，把第 6 小节的双预算翻译成云的档位语言；很多云上"存储忽快忽慢"的悬案，答案是突发额度的信用耗尽——基准性能与突发额度的区别，是云盘时代的页物理学。

再送一句云时代的选型心法：云盘档位的选择本质是"买基准还是买突发"——稳定负载买基准性能（便宜且稳）、波动负载看突发额度（贵但弹性），把业务流量画像（基准线与尖峰的形态）翻译成档位决策；这个翻译动作做好，云存储的账单能与性能同时优化，做不好就是"花了突发价、买了基准命"——云时代的调优师，一半是翻译官。

作者与出处

原作者：灏天文库

来源：灏天文库

整理：灏天文库整理

由灏天文库平台收录，内容或由平台用户上传，仅供学习交流