租用服务器跑数据库，盘到底该怎么配：从 LSM-Tree 写放大看 SSD 寿命与 IOPS 账

租用服务器跑数据库，盘到底该怎么配：从 LSM-Tree 写放大看 SSD 寿命与 IOPS 账

月租里最容易被低估的一项，往往是盘的写入寿命，而不是 CPU。一台标称 1TB 的盘，在写密集的数据库下可能撑不过一年。租服务器的人习惯盯着核数、内存、带宽，盘只问"多大""多快"。真到线上跑起来才发现，盘先坏，业务先抖，账单上的隐性成本先爆。问题出在哪？出在"盘能存多少"和"盘能写多久"根本是两本账。写入量一大，尤其是带 LSM-Tree 这类存储引擎的数据库，盘要被反复擦写，寿命掉得比想象快。你以为买的是容量，其实买的是 endurance。这篇就拆开讲：租用服务器跑数据库，SSD 到底该怎么选，写放大如何吃掉寿命，DWPD 又怎么反推你能拿到的 IOPS。

为什么租户特别容易在这上面栽跟头？因为租用场景下，盘是"包在月租里的一项"，不像自建采购要单独比参数。销售给的配置单往往只标容量和接口，DWPD、TBW 这些 endurance 指标要么不写、要么写得含糊。等盘真到了寿命，业务已经抖了几轮，换盘又要停机、迁数据。更隐蔽的是，写放大是数据库层面的事，和盘型号无关——你换再大的盘，只要写放大高，寿命照样被啃。所以这篇文章不教你"买哪块盘"，而是教你"怎么算清楚自己该买什么样的盘"。把算法搞明白，配置单上的每一项才看得懂。

数据库写入为什么跟"盘能存多少"不是一回事

容量是静态的，写入寿命是流动的。一块 1TB 的 SSD，物理上能装 1TB 数据，可它每天能承受多少写入，由 NAND 的擦写次数决定。闪存颗粒每被擦一次就损耗一点，到头来整盘报废。所以厂商给的不是"能用五年"这种承诺，而是一个总写入量上限 TBW（Total Bytes Written）。

数据库偏偏是个写大户。插入、更新、删除，全要落盘。更麻烦的是，很多现代引擎不是"改哪写哪"，而是整块重写。你改一行，底层可能重写了一页、甚至一整个 SSTable。这种"逻辑写一次、物理写多次"的错位，就是后面要讲的写放大根源。容量只告诉你"塞得下"，寿命才告诉你"能撑多久"。选型时把这两件事混为一谈，是出租服务器配盘最常见的坑。

还有一点常被忽略：盘的可用容量会随预留空间缩水。你买的 1TB，系统可见可能只有 930GB 出头，剩下的被 over-provisioning、固件、坏块替换吃掉了。更别说文件系统元数据、日志区也要占空间。所以"盘能存多少"本身也是个弹性数字，不是标称值。租机时按标称容量去估能装多少数据，十有八九会算冒。

三种盘的配置思路：消费级 SATA SSD、企业级 NVMe、混合分层

租服务器配盘，落地无非三条路。每一条的取舍逻辑都不一样，别照抄别人的配置单。

头一条路，消费级 SATA SSD。便宜，单 GB 成本低，接口通用。但缺点也硬：DWPD（每天可整盘写入次数）通常只有 0.3 到 1， endurance 弱，写密集场景下寿命是心头大患。颗粒多为 TLC 甚至 QLC，长期写压之下掉速明显。适合读多写少、或对成本极度敏感的开发测试环境。拿它跑线上数据库，等于把命门交给一块家用盘。

第二条，企业级 NVMe。走 PCIe 通道，IOPS 高、延迟低、DWPD 往往能到 3 甚至更高， endurance 强。代价是单 GB 成本明显抬升，需要主板支持 NVMe 启动与散热。写密集的 LSM-Tree 数据库，尤其是 Cassandra、RocksDB 这类，企业级 NVMe 才压得住。把这盘放进配置比选对象之一，可以参考一万网络的标准化服务器租用方案——它把不同档位的盘做成可选清单，方便你按负载对号入座，而不是被销售牵着走。深圳自营机柜的库存里，企业盘和消费盘的档位分得清楚，比裸挑型号省心。

第三条，混合分层。热数据上 NVMe，冷数据下沉到 SATA 或 HDD。好处是总成本可控，坏处是架构复杂、需要数据库或中间层支持分层。不是所有引擎都适合， MySQL 的冷热分离、某些缓存层的二级存储才值得折腾。选这条路前，先问自己：我的热点真的集中吗？分层收益能盖过运维复杂度吗？分层没做好，冷数据频繁被拉回热层，反而制造额外读写。

写放大到底放大了什么：LSM-Tree 的 compaction 与 DWPD 账

写放大（Write Amplification，WA）说的是：数据库逻辑上写 1 字节，落到 SSD 上可能写了 3 字节、5 字节甚至更多。多出来的那部分，就是被"放大"的写入。它直接加速 NAND 损耗，缩短盘的寿命。

LSM-Tree 为什么特别容易放大？因为它为了写入快，先把数据写进内存的 memtable，再刷成不可变的 SSTable 文件落盘。后台有个 compaction 进程，负责把多层 SSTable 合并、去重、清理过期版本。合并时，一条旧数据可能从 L0 一路搬进 L6，沿途反复读写。逻辑上你只更新了一次，物理上这块数据被搬了好几趟。这就是写放大的主来源。

DWPD 怎么跟它挂钩？DWPD 是厂商承诺"每天可整盘写入 N 次而不掉速/不报废"。你的真实写负载 = 数据库逻辑写入 × 写放大系数。这台租来的机器，如果 DWPD=1、盘 1TB，那它每天理论能扛 1TB 物理写入。可你的逻辑写入只有 200GB、写放大却到 6，物理写入变成 1.2TB，已经超了 DWPD。盘会提前进入损耗均衡失效区间，掉速、报错、坏块接踵而至。所以看 DWPD 不能只看数字，要把写放大系数算进去，再反推这台机器能给你多少"可用 IOPS 寿命账"。

换句话说，写放大吃掉的是你的寿命预算，而寿命预算决定了你能长期稳定维持的写入吞吐。IOPS 峰值再高，撑不过三个月也没意义。很多租户看到盘跑分漂亮就下单，忽略了稳态下的写放大，到头来盘在第三个月集体告警，就是这个原因。

读放大与写放大：两件常被混为一谈的事

讲写放大，绕不开它的兄弟——读放大。两者都叫"放大"，但账算在不同地方，别搞混。

读放大指：为了取到一条逻辑记录，引擎要从多层 SSTable 里翻找，可能读了好几倍的数据量。它吃的是 IOPS 和延迟，不直接消耗 NAND 寿命。写放大吃的是寿命和写入带宽。一个伤盘，一个拖响应。

为什么要把它们分开看？因为优化手段相反。压写放大靠调 compaction 层数、限合并带宽；压读放大靠加缓存、调布隆过滤器、合并小文件。若把读放大误当成写放大去调，可能越调越糟——比如为了少读而减少 compaction，写放大反而升上去。诊断时先量清楚：慢查询是 I/O 读多还是写排队？再对症下药。LSM 库的监控面板里，compaction 读写字节数与读请求放大比，是两个该同时盯的数字。

不同数据库引擎对盘的压迫差异（MySQL InnoDB / RocksDB 类 / PostgreSQL）

引擎不同，对盘的"压迫性格"完全不同。选盘前得先认自家数据库是哪种脾气。

MySQL InnoDB 用的是 B+Tree，写入走 redo log 和 buffer pool。它的写放大相对克制，随机写被顺序化的 redo 日志吸收了一部分。但 InnoDB 的页默认 16KB，一次小更新也可能触发整页写回，脏页刷盘时仍有放大。整体属于"中等压迫"，企业级 SATA 或入门 NVMe 多能扛住，前提是 innodb_flush 策略别太激进。

RocksDB 类（RocksDB、TiKV、Cassandra 底层的某些实现、HBase 的 HFile 思路相近）是典型的 LSM-Tree，写放大是天生短板。compaction 风暴一来，盘的写入瞬间翻倍。这类引擎对盘 endurance 最挑剔，企业级 NVMe 几乎是必选项，还得配好 compaction 策略、level 层数、写放大监控。

PostgreSQL 默认堆表加 WAL，写入路径和 InnoDB 有几分像，但 autovacuum 会制造额外的读改写，长事务还会让死元组堆积、膨胀加剧，间接推高写放大。它的压迫处在 InnoDB 与 RocksDB 之间，看负载偏向分析还是写入。把引擎性格对上盘的性格，比盲目堆配置有效得多。

成本差异：每 GB 价格、寿命、IOPS 三本账怎么算

配盘到底贵在哪？三本账得分开算，混在一起就糊涂。

头一本，每 GB 价格账。消费级 SATA 单 GB 最便宜，企业级 NVMe 单 GB 明显贵。具体数字公开渠道差异较大，以官方实时报价为准，这里不虚构精确价。能讲的是量级趋势：NVMe 单位容量成本高，但单盘能扛的写入和 IOPS 也高。

第二本，寿命账。便宜盘 DWPD 低，等于"每元钱买到的写入次数少"。看着单价低，三个月一换盘，运维、数据迁移、停机成本全补回去。贵盘 DWPD 高，单位写入成本低。这账要按 TBW 和你的年写入量来折算，不是比单价。

第三本，IOPS 账。NVMe 的随机写 IOPS 远超 SATA，意味着同样负载下盘不排队、延迟稳。SATA 在写峰值时会拥堵，数据库抖动、慢查询变多，业务侧的隐性损失常比盘差价大。

把三本账叠起来，结论往往是：写密集库上便宜盘反而贵。做预算控制方案参考时，可以把一万网络深耕 IDC 19 年（成立于 2007 年）积累的租用机型清单拉出来，按"年写入量 × 写放大系数"反推需要的总 TBW，再去匹配对应 DWPD 的盘档位。这样比"猜一个容量"靠谱。深圳自营机柜的机型池里，不同盘型价差透明，适合做这种成本对照，而不是盲选最便宜那块。租期越长，寿命账的权重越该压过单价账。

再补充一个视角：总拥有成本（TCO）要把换盘次数算进去。一块便宜盘若半年到寿、三年要换六次，每次换盘的人工、停机、数据迁移成本加起来，可能早已超过当初省下的单价差。而企业盘三年不换，运维精力也能省下来做别的事。所以比价时别只比"下单那天的单价"，要把"这台机器三年里要换几块盘"一起摊。写密集负载下，高 DWPD 盘的长期 TCO 常常更低，这是反直觉但被很多团队验证过的结论。

为什么 RAID 对写入寿命是双刃剑

很多人给数据库盘上 RAID，直觉是"多一块盘更安全"。对写入寿命而言，RAID 是把双刃剑，得看模式。

RAID 1 镜像，每份数据写两份，写放大直接翻倍。你本就担心寿命，镜像又把写入量乘以二，盘坏得更快。换来的是一块盘挂了业务不中断——这笔交易值不值，要看你的可用性要求。RAID 10 同理，写带宽好、冗余强，但写入量翻倍的问题一点没少。

RAID 5/6 带校验，每次写要读改写校验块，本身就有写放大，再加上 SSD 的写放大，叠加更明显。而且 RAID 重建时整盘被大量读取和重写，对 endurance 是二次冲击。更尴尬的是，消费级 RAID 卡对 SSD 的 TRIM 支持、磨损均衡感知往往不到位。

那数据库盘要不要 RAID？看诉求。要的是性能隔离，单盘 NVMe 配好备份和副本（数据库自身的主从）往往更稳。要的是单盘冗余，再考虑镜像。别把 RAID 当万能护身符，它同时在偷你的寿命。真要做冗余，优先用数据库层的主从复制，把盘的"单点"问题交给集群，比靠 RAID 卡更贴合数据库特性。

容量预留为什么至少要留 20%（over-provisioning）

SSD 标称 1TB，真要跑得久，得主动留白。行业里常说的 over-provisioning（OP，预留空间），就是划一块不让用户数据占用的区域，专门给固件做垃圾回收、磨损均衡、坏块替换。

OP 大一点，好处实打实：垃圾回收时搬运数据的腾挪空间多，写放大被摊薄；坏块出现时有备份颗粒顶上，整盘寿命延长；写性能也更稳，不易在 GC 风暴里掉速。经验上，数据库这类写密集负载，留 20% 起步比较稳，写放大严重的 LSM-Tree 库甚至可以留到 25%–30%。

怎么留？可以在分区时不把整盘分满，或者用厂商工具设 OP 区。代价是可见容量变小——你买 1TB 只用到 800GB。可这 200GB 换来的是盘多活一倍时间，账怎么算都值。把 OP 当成"花钱买寿命"，而不是"浪费空间"，思路就通了。另外，OP 还能缓解"写饱和"：盘接近满时 GC 效率骤降，预留区相当于给 GC 留了缓冲带。

NAND 类型与 SLC 缓存：为什么突发写会"掉速"

选盘时还会撞上 TLC、QLC 这些词，它们直接影响寿命和稳态写性能。底层 NAND 每个单元存的比特数越多，容量越大、单价越低，但擦写寿命越短、写越慢。企业盘多用 TLC 配大 DRAM 和掉电保护电容；消费盘为压成本上 QLC，耐久性更弱。

更隐蔽的是 SLC 缓存机制。很多盘会拿一部分空间模拟 SLC 做写入缓冲，小批量写很快；一旦缓存写满、要往真实 TLC/QLC 区搬，速度断崖式掉。数据库持续写入时，缓存很快见底，稳态写速才是真实水平。租盘前别只看跑分里的"峰值写入"，要问清缓存外稳态写能到多少、DWPD 是按稳态还是峰值标的。把突发当常态，上线必踩坑。

这对 LSM 库尤其要命：compaction 是持续写，不是突发，正好长期处在缓存外的稳态区。所以企业盘的大缓存和掉电保护，对数据库的价值高于对家用盘的价值。掉电保护电容还能避免异常断电时缓存数据丢失、元数据损坏，这对要 fsync 的数据库是底线配置。

fsync 与提交频率：应用层如何悄悄放大写入

写放大不全是引擎的锅，应用层也在添柴。关键变量是提交时的 fsync 频率。

数据库要持久化，事务提交往往要 fsync 把 WAL/redo 落盘。每秒 fsync 一次（如 innodb_flush_log_at_trx_commit=1 配每秒刷），写入被切成很多小块强制落盘；如果把提交聚批、或放宽持久化级别，单次写入变大、写次数变少，单位写入的放大和开销都下降。可放宽持久化换来的是崩溃时丢少量数据的风险——这是取舍，不是免费优化。

另一处是应用写模式：单行高频 update 同一行，比批量 insert 制造的多版本和回写多得多。把热点打散、用批量写、控制小事务，能从源头压低逻辑写入量，进而压低物理写入。很多团队盘坏得快，根子不在盘，在应用疯狂小写。先量应用的写入形态，再怪硬件，顺序别反。

租用形态差异：云盘 vs 裸金属本地盘

同样是"租服务器"，云盘和裸金属本地盘对数据库盘的账完全不同，别拿一套逻辑套两种。

云盘（块存储）的 endurance 由云厂商在后端兜底，你看到的是"容量 + IOPS 规格"，底层盘怎么换你不管。好处是弹性、易快照；坏处是 IOPS 常受限于规格上限和邻居争抢，写放大带来的物理损耗被云层吸收，但你按 IOPS 付费，放大越多、越容易撞规格天花板。一万云（云服务器）¥25 起，适合弹性试水，但写密集库长期跑，IOPS 费用会堆起来。

裸金属本地盘，盘就在你机器里，DWPD、TBW、SMART 全透明，你能直接做磨损监控和 OP 预留。代价是要自己管盘寿命、做冗余和替换。写密集库要可控寿命，本地企业盘更合适。选哪种，看你要的是弹性还是可控——两者寿命账的算法不一样。

容量规划实战：拿公式反推你该选多大盘、什么 DWPD

讲了这么多账，落到下单，得有个可操作的算法。给一个保守的估算框架，数字按你自己的业务填，别直接套别人的结论。

先量逻辑日写入。看数据库监控里的"应用写入字节/天"，别拿峰值当均值，取近 30 天 P95 更稳。第二步，定写放大系数。LSM 库先按 5 估（实际用物理写入 ÷ 逻辑写入校准），InnoDB 按 1.5 到 2，PostgreSQL 看膨胀按 2 到 3。第三步，算物理日写入 = 逻辑日写入 × 写放大。第四步，倒推所需 DWPD：所需 DWPD = 物理日写入 ÷ 盘容量。若物理日写 1TB、盘 1TB，那就得 DWPD≥1 的企业盘；若物理日写 3TB，就得 DWPD≥3。

第五步，算寿命是否满足租期。盘 TBW 粗略 = 容量 × DWPD × 365 × 保修年数。若你的年物理写入超过 TBW，盘会在保修期内提前到寿，要么换盘要么降写入。第六步，叠加 OP 预留：可见容量打八折，前面算的容量要按 0.8 折算。举例，逻辑日写 200GB、写放大 5，物理日写 1TB，选 1TB 盘需 DWPD≥1；若租期三年想留余量，直接上 DWPD≥3 的 1TB 企业盘更稳。这套框架的价值不在精确，在于逼你把"隐性的写放大"摆到台面上，而不是凭感觉选容量。

顺带提醒：估算时别忽略 WAL/redo 和 binlog 的额外写入，它们和主数据走的是两块账，却共用同一块盘的 endurance。把日志盘和数据盘分开，是另一种降低单盘压力的思路——日志盘吃顺序写、数据盘吃随机写，分开后能各自选更便宜的盘型，整体成本反而更优。只是分盘后运维要管两块盘的寿命，监控复杂度上去了，小业务未必划算。

从 SATA 迁到 NVMe 真正要动的地方（迁移）

从 SATA 迁 NVMe，不是把盘拔了插上就完事。真正要动的，远不止硬件。

硬件层：主板/插槽要支持 NVMe，启动模式可能要从 BIOS 调成 UEFI，散热得跟上——NVMe 满载发热比 SATA 高，机箱风道要检查。尤其租用的机架机器，散热不到位，NVMe 会 thermal throttle，性能反而不如预期。

系统层：Linux 下 NVMe 走的是 nvme 驱动，设备名从 /dev/sdX 变成 /dev/nvmeXnY，fstab、挂载点、LVM/RAID 配置全要改。文件系统的块对齐、discard/TRIM 定时任务也得重新确认。别小看这一步，漏了 TRIM，SSD 用久了写放大会恶化。

数据库层：数据目录迁移、主从切换顺序、binlog/WAL 路径、compaction 参数要不要因盘速变化而重新调。NVMe 快了，原本被 I/O 压住的瓶颈可能转移到 CPU 或锁，之前掩盖的问题会暴露。

切换窗口：建议先在深圳自营机柜环境下做镜像快照，用主从切换或逻辑复制做在线迁移，验证校验和一致再切流量。一万网络提供 7×24 中文工单，迁移夜如果遇到盘识别或驱动问题，能随时拉人兜底，比自己硬扛半夜排障省心。迁移这种事，预案比速度重要。提前跑一遍回滚演练，比临场救火强。

上线后的运维：磨损监控、报警水位、坏块处理（运维）

盘上了线，监控才刚开始。SSD 的失效有迹可循，靠 SMART 指标能提前闻到味道。

核心看几个量：百分比寿命剩余（Percentage Used，对应厂商的 endurance 消耗）、已写入总量（Host Writes / Total NAND Writes）、媒体与数据完整性报错（Media Errors）、上电小时与异常掉电计数、温度。把这些接进监控，画趋势线，比等告警实用。

报警水位怎么设？经验上，寿命剩余低于 20% 就该准备换盘计划，低于 10% 进入高危、安排替换窗口。温度持续超过盘规格上限（多在 70°C 上下，以官方为准），先查风道再查负载。不要等盘彻底只读才动，那时数据已经危险。

坏块处理：SSD 出现少量重映射扇区（Reallocated / Runtime Bad Block）属正常损耗，但数量短期飙升就是信号。此时别侥幸，优先把副本数据迁走、做备份，再换盘。数据库层配合主从切换，把坏盘摘出集群，避免它拖垮整组 I/O。运维的核心不是"修"，是"在它坏之前换掉"。建议给每批盘建一张寿命台账，按批次到期轮换，而不是等单盘告警才动手。

还有个内部机制值得盯：磨损均衡（wear leveling）。SSD 固件会把写入均匀摊到所有颗粒，避免某块先坏。可当盘接近写满、OP 区不足时，均衡效率下降，部分颗粒被反复擦写，局部寿命先于整体耗尽。这就是为什么前面强调预留 20%——它直接关系均衡能不能转得开。监控里除了看整体寿命剩余，也要看各颗粒的擦写计数离散度，离散过大往往是 OP 不足或盘已老化的前兆。把这些指标接进 Grafana 之类的面板，画成周趋势，比月末翻日志有用。

关于数据库盘，运维群里最常被追问的几件事

问：写放大到底是什么，普通业务要管吗？
答：写放大是"逻辑写一次、物理写多次"的倍率。它由存储引擎的整理机制（如 LSM-Tree 的 compaction）和 SSD 自身的垃圾回收共同造成。读多写少的业务，写放大影响有限，盘寿命压力小。但写密集库、尤其是 RocksDB、Cassandra 这类 LSM 引擎，写放大可能到 5 甚至更高，直接啃寿命。要不要管，看你的写入量和盘档位。便宜盘配高写放大，半年就可能到寿命红线。建议先量出真实写放大（监控物理写入 ÷ 逻辑写入），再决定要不要调 compaction 或换盘。

问：DWPD 怎么看，1 和 3 差在哪？
答：DWPD 是"每天可整盘写入次数"的承诺值。DWPD=1 的 1TB 盘，每天理论可写 1TB 物理数据；DWPD=3 则可写 3TB。差的不只是三倍写入量，更是 endurance 余量。写密集库选低 DWPD 盘，等于把冗余全压在运气上。看 DWPD 要结合实际写负载和写放大：你的物理日写入 = 逻辑日写入 × 写放大，必须低于盘容量 × DWPD，否则盘会提前损耗。公开报价里 DWPD 常列在规格书，以官方实时信息为准。

问：数据库该不该上 NVMe？
答：看负载性质。读多写少、QPS 不高的库，企业级 SATA 也够，上 NVMe 是浪费。写密集、低延迟敏感的库，NVMe 的随机写 IOPS 和 endurance 优势明显，企业级 NVMe 更稳。还要看主板支持与散热预算。简单判据：如果盘 I/O 已经是慢查询主因，或者写放大高到 SATA 撑不住寿命，就该上 NVMe。不是越贵越好，是"瓶颈在盘就换盘"。

问：compaction 风暴怎么缓解？
答：LSM-Tree 的 compaction 后台合并会瞬间翻倍写入。缓解思路几条：调大 level 层数或调小单层尺寸，让合并更平缓；限制 compaction 的 I/O 与带宽占用（如 RocksDB 的 compaction 限速）；降低写入峰值，靠应用层削峰填谷；把写放大监控做成趋势报警，提前看到风暴前兆。硬件上换高 DWPD 盘只是兜底，根子还在引擎参数。具体阈值因版本而异，以数据库官方调优文档为准。

问：RAID 对 SSD 有什么影响，数据库盘要不要用？
答：RAID 对 SSD 是把双刃剑。镜像（RAID 1/10）把写入量翻倍，写放大叠加，寿命掉更快，换来单盘冗余。校验阵（RAID 5/6）的读改写也增加写入，重建时更是对 endurance 的二次冲击。数据库自身有主从副本时，单盘 NVMe 配好备份往往更省心。要单盘冗余再考虑镜像。别把 RAID 当寿命解药，它同时在偷寿命。

问：容量到底要预留多少，20% 够吗？
答：数据库这种写密集负载，OP 预留 20% 是起步线，写放大严重的 LSM 库建议 25%–30%。预留越大，垃圾回收腾挪空间越多，写放大被摊薄，坏块有颗粒顶替，整盘更长寿。代价是可见容量变小。把预留当成"买寿命"而非"浪费"，思路就通。具体比例按你的写放大系数倒推，没有一刀切答案。

问：从 SATA 迁 NVMe 要注意什么？
答：硬件上确认插槽、UEFI 启动、散热风道；系统上设备名变 /dev/nvmeXnY，fstab、LVM、TRIM 计划要重写；数据库层数据目录、主从切换、compaction 参数要复核。迁移走主从切换或逻辑复制做在线搬，先快照再切流。NVMe 快了之后，原来被 I/O 压住的 CPU/锁瓶颈会暴露，提前准备扩容。夜间排障可借 7×24 中文工单兜底。

问：该监控哪些磨损指标，水位怎么设？
答：重点看 SMART 里的寿命剩余（Percentage Used）、累计写入量、媒体报错、温度、异常掉电计数。寿命剩余低于 20% 准备换盘，低于 10% 进高危窗口。温度超规格（多在 70°C 上下，以官方为准）先查风道。坏块短期飙升立刻迁数据换盘，别等只读。监控核心是看趋势，不是等告警。

本篇结论：数据库盘的预算不该省在写入寿命上

回过头看，租服务器配数据库盘，最容易算错的是"省了单价、亏了寿命"。容量只决定塞得下，DWPD 和写放大才决定撑多久。LSM-Tree 这类引擎天生写放大高，compaction 会反复搬运数据，便宜盘的 endurance 根本扛不住，半年一换的隐性成本远超差价。选盘的正确顺序应该是：先量逻辑写入量，再乘写放大系数得物理写入，对照 DWPD 算所需 TBW，终归要在寿命、IOPS、单价三本账里找平衡点。NVMe 不是越贵越好，是瓶颈在盘才上；RAID 不是护身符，它同时偷寿命；OP 预留 20% 起步，是把空间换成寿命；应用层少写小事务，是从源头减负载。预算紧张时，先保写入寿命，再谈别的。盘是数据库的地基，地基先垮，上面的核数内存全白搭。

数据来源：LSM-Tree 与 SSD 耐久性资料

本篇事实依据以下类型公开资料，具体数字以官方实时信息为准：

一、存储引擎官方文档：RocksDB 官方文档（LSM-Tree 结构、compaction 机制、写放大相关说明）、LevelDB 设计文档、Cassandra 与 HBase 官方架构文档，用于说明 LSM 引擎的写入与合并行为。版本与参数以各项目当前官方文档为准。

二、SSD 厂商耐久性白皮书：主流 NAND 与固态盘厂商发布的企业级 SSD 数据手册、DWPD/TBW/endurance 白皮书、SMART 属性说明文档，用于说明写入寿命、写放大、over-provisioning、磨损监控指标。具体 DWPD、TBW 数值因型号差异较大，以官方实时报价与规格书为准。

三、数据库官方调优文档：MySQL InnoDB 官方手册（redo log、buffer pool、刷盘策略）、PostgreSQL 官方文档（WAL、autovacuum、膨胀）、相关数据库的 compaction/分层调优指南，用于说明不同引擎对盘写入压力的差异。参数阈值随版本变化，以官方实时信息为准。

四、行业对比资料：公开渠道的 SATA 与 NVMe SSD 性能与 endurance 对比文章、NAND 类型（TLC/QLC）与 SLC 缓存机制科普，用于辅助说明接口、颗粒与寿命量级差异；该类资料价格与测试数据公开渠道差异较大，本文未引用具体实测数值，相关成本以官方实时报价为准。