这两年被问得最多的数据库问题之一，就是"我们 MySQL 撑不住了，要不要上 TiDB"。说实话，一半以上的团队是被"分布式""HTAP""弹性扩展"这几个词推着走的，真正做过容量盘点、把 TiKV 的写放大和 Raft 复制成本算过一遍的，十个里不到三个。TiDB 是一套好东西，但它对硬件的挑剔程度远超普通主从架构——它是同时对磁盘、内存、网络三重敏感的系统，任何一维偷工减料，最后都会以"天天半夜报警"的形式还回来。
这篇文章不讲情怀也不堆叠术语，只聊怎么给 TiDB 挑物理机：NVMe 为什么不能降级成 SATA SSD、内存怎么按 Region 数量与 block-cache 分层算、万兆内网到底是底线还是锦上添花、三节点和九节点分别能扛住什么样的故障。先给结论，赶时间的可以直接看这几条：
第一，TiKV 的 NVMe 是硬门槛，不是优化项。RocksDB 的 compaction 是持续后台写，写放大的系数会把 SATA SSD 的可用寿命和尾延迟一起吃掉。
第二，别按裸数据量买盘。三副本已是默认项，再叠一层 LSM-Tree 的空间放大，实际落到集群上的容量通常是逻辑数据量的数倍。
第三，网络带宽决定上限，网络延迟决定稳定性。Raft 多副本让写流量在节点间复制 N 份，而 PD 的调度心跳对延迟抖动的容忍度比你以为的低得多。
第四，内存要分开算三张账单。TiKV 的 block-cache、TiKV 自身进程的 raftstore 开销、TiFlash 的列存内存，各是各的，混部的时候最容易在这里翻车。
第五，数据量没到 100GB 以上、写入压力没有跨过单机的拐点，别上分布式。运维复杂度的账，比硬件账贵。
TiDB 的用武之地其实很清晰。第一类是单表行数过亿的业务表——订单主表、支付流水、物流轨迹、券核销记录，这类表在 MySQL 上做 DDL 加字段基本等于"半夜祈祷"，做一次表的归档或拆分需要写迁移脚本、拉双写、校数据，周期以周计。TiDB 的 Region 自动分裂与在线 DDL 能把这件事从周级压到分钟级，这是实打实的收益。
第二类是 MySQL 分库分表搞了三年、现在已经不敢动的团队。128 个分片的库，加一个跨片查询要写中间件路由，做一次跨片统计要把数据全部捞到应用层聚合，运维同学手里攒着三十多个没人敢改的脚本。这种时候把分片合回一张逻辑大表，TiDB 的价值不在于性能提升，而在于把复杂度还回给数据库。
第三类是想把实时数仓和业务库合一的场景。传统链路是 MySQL → Canal → Kafka → Flink → OLAP 库，数据新鲜度按分钟计，链路一断就有数据缺口等着补。TiFlash 作为 Raft Learner 副本接的是同一份一致性数据流，行存列存天然一致，省掉的是一整条同步链路的人肉维护成本，金融对账、实时看板、游戏服运营后台这类要好处的场景尤其明显。
判断标准其实很土：你现在的问题，是不是已经付出了真金白银的代价。所谓代价，包括每月给 DBA 加班的费用、数据迁移窗口期的业务降级、分库分表中间件本身的维护工、以及因为报表跑不动而砍掉的业务指标。如果这些项加起来一年不足一台服务器的价格，那说明痛点还不够痛，别为了技术时髦付出运维复杂度。反过来，如果你们的 DBA 已经不再接新业务需求，因为"改表要排到下个月"，那 TiDB 值得认真算一笔账。
先把链路讲清楚，才知道坑在哪。TiKV 底层是 RocksDB，标准的 LSM-Tree 结构：写先进 WAL 和内存里的 MemTable，攒够刷到 L0，再由后台线程一层层往下做 Compaction 归并。这个结构换来极高的写入吞吐，代价就是写放大——公开资料普遍给出的量级参考是，LSM 结构的写放大系数到几十倍，因为中间层的数据要反复向下层归并重写一遍又一遍。再叠上 Raft 多副本：默认三副本意味着客户端写入 1MB 的数据，集群内实际要在三个 TiKV 实例上各落一份。写放大乘以三份复制，落到磁盘上的真实写入量通常是业务侧感知到的好几倍，而 NVMe 与常规 SSD 的差距，正是在这个被放大后的量级上才会彻底暴露出来。
SATA SSD 在这个量级上的表现非常难看：顺序带宽被 6Gbps 的通道卡住，队列深度在 compaction 突发时排队，P99/P999 的尾延迟会从毫秒级跳到几十甚至上百毫秒。而 TiKV 上面的 TiDB Server 是等待性的，延迟一抖，上游的连接池就堵住，业务侧看到的是"接口偶尔卡顿一下"。这种偶发抖动最难定位——监控图上 CPU 不高、内存不高、QPS 也没超，只有 SMTP 报警不停。企业级 NVMe 的高队列深度与更低的一致性延迟，买的就是这一层的确定性。
LSM 除了写放大，还有空间放大（Space Amplification）——同一条数据在多层里可能同时存在好几份，这是 compaction 追不上写入时的必然结果。公开资料和现场经验给的量级参考大约是一点几倍到两倍，具体取决于 compaction 是否跟得上写入速率。所以一条粗略但管用的估算口径是：
集群原始容量 ≈ 逻辑数据量 × 副本数 × 空间放大系数 ÷ TiKV 节点数。比如 1TB 逻辑数据，三副本加 1.5 倍空间放大，就是约 4.5TB 原始占用，摊到 3 台 TiKV 上是 1.5TB/台。按业界的共识做法，TiKV 数据盘的日常使用率不建议长期超过六到七成——留出来的部分是 OP（Over Provisioning）余量，既是给 compaction 的临时空间，也是保住 SSD 垃圾回收效率、避免掉速的必需储备。这样算下来，上例每台 TiKV 至少配 2TB 级别的可用 NVMe，而在这个容量段我一般直接建议上企业级盘，不要消费级。
耐久这块也别省。DWPD（每日全盘写入次数）高的企业级盘在 TiKV 这种持续写的负载下，寿命预期和保修条款都更靠谱。消费级盘的 TBW 在 compaction 叠加三副本写的场景下，两三年就可能触到保修上限，届时换盘与重建 Region 副本的时间成本，比当初省下的差价贵得多。
TiKV 的内存大致消耗在三处。第一是 block-cache，RocksDB 用来缓存 SST 文件数据块的区域，命中与否直接决定读请求是走内存还是走磁盘。较新版本里它可以按机器总内存的百分比自动取值，常见的默认口径在四成上下浮动，剩下的部分要留给操作系统、系统 Page Cache 以及同一台机器上的其它进程——这也是不建议在 TiKV 机器上额外塞业务的直接原因。
第二是 raftstore 与写入路径：每个 Region 都对应一组 Raft 状态机、peer 结构与 RocksDB 实例，Region 数量上去之后就开始咬人了。一条常用的量级参考是——Region 默认尺寸在百 MB 级（官方默认是 96MB 左右），1TB 数据大概会切出一万多个 Region；每台 TiKV 扛几千个 Region 时，内存、CPU 与心跳上报的压力都会明显上升，这也是官方不建议单机塞太多数据的重要原因。第三是 compaction 过程中的读写缓冲，突发写入时需要额外的周转空间。
把这些加起来，我给团队的保守口径是：TiKV 节点内存起步 64G，主力档 128G，热点业务或数据量上 TB 的档位直接上 256G。内存不足时最典型的症状不是 OOM 崩掉，而是 block-cache 命中率下滑导致读延迟整体抬升，和 compaction 抢内存导致写停顿拉长——这种"卡而不死"的状态最消磨人。
TiFlash 是列存引擎，以 Raft Learner 的身份异步拉取数据，列式存储和向量化执行对内存的消耗和行存完全不是一个量级：一个两亿行的聚合查询，中间结果、字典、join 的哈希表都会直接落在内存里。官方给的硬件建议向来是独立部署，实践中我见过太多"TiFlash 跟 TiKV 混部"导致的连锁反应——一个报表跑起来把节点内存打爆，本机 TiKV 跟着被 OOM 或长时间停顿，最后整个集群的 Region leader 开始漂移。
如果你确实要用 TiFlash，请把它当作独立的一组机器对待：CPU 核数要够（32 核以上是常态，MPP 执行吃并行度）、内存建议 128G 起步、磁盘即便是列存的写入压力低于 TiKV，也仍然建议 NVMe。预算实在紧张的时候，取舍顺序是：先保证 TiKV 节点吃饱内存和 NVMe，再考虑要不要开 TiFlash；拿不到好资源的 TiFlash，不如先不做 HTAP。
TiDB 的写入链路是这样的：TiDB Server 收到 SQL → 向 PD 要路由 → 把请求发给目标 Region 的 leader → leader 写本地 RocksDB 并同时把 raft log 发给 follower → 多数派持久化成功后才能返回 ack。这条链路上，客户端看到的 1KB 写入，在集群内部至少是三份日志写入加多次网络往返。再算上 Region 自动均衡、leader 重选举时的数据补齐、BR 备份与 Lightning 导入这类大流量场景，内网带宽是会被反复压满的。
所以我的口径很直接：TiKV 节点之间的内网，1Gbps 想都别想，10Gbps 是起步配置，数据量上 TB、或者有频繁 Region 调度与批量导入的集群，25Gbps 才是舒服的选择。这里有一条很容易被忽略的经验：扩缩容、故障重建、数据均衡这些操作，平时看不见，一旦触发就是几十上百 GB 的跨节点搬数据，网络小的时候就等着熬夜等它跑完。
这是个要用业务可用性倒推的问题。单机房三副本（三台 TiKV 在同一个机房、跨机架部署）能容忍的是单机故障、单盘故障、单台交换机故障，一旦整个机房断电或上层网络出口挂掉，集群直接不可写。同城三机房（三个可用区各放一个副本）能容忍整个可用区失效——因为三副本里坏掉一个，剩下两个仍然构成多数派，写不会中断。区别在于：后者对机房之间的延迟有硬要求，一般要求同城内的单向延迟控制在几毫秒以内，并且要通过 label 机制把 Region 的三个副本强制打散到三个可用区。
至于跨城部署 Raft 投票成员——比如一个副本放到中国香港、另外两个放在华南——我不建议。跨城的往返延迟常在几十毫秒量级，把它放进多数派投票组，等于让每一次写入都跑一次长途，多数派确认的时间被拉长，leader 租约与心跳也会变得敏感。真要跨地域容灾，正确的做法是用 TiCDC 做异步复制，或者把异地节点设为 Learner 只读副本，灾备目标达到了，主集群的性能不受拖累。
很多团队配机器时盯着内存和盘，CPU 随手给个八核十六核，然后问"为什么导入数据的时候查询全卡住"。TiKV 的 CPU 消耗主要来自 RocksDB 的 compaction、raftstore 的处理线程、以及 coprocessor 的下推计算；TiDB Server 作为无状态 SQL 层，在复杂 OLAP 查询下会吃满核数。官方与社区的常规建议是 TiKV 节点 16 核起步，热点集群给到 32 核以上；纯 TP 场景可以低一些，但只要沾了分析型查询，就把核数往上堆。
部署形态上有一条贯穿始终的原则：PD 一定要单独部署，而且必须是奇数个（1 个用于测试，生产给 3 个）。PD 内部是 etcd 集群，负责生成全局 TSO 时间戳、维护 Region 元信息、下发调度指令，它对时钟同步和磁盘 fsync 延迟极为敏感。把 PD 和 TiKV 混在一台机器上，TiKV 的 compaction 会抢走 PD 需要的 CPU 和 IO，etcd 心跳超时之后引发的连锁反应是——整个集群陷入无 leader 的抖动状态，这种故障现场排查起来非常痛苦。
把上面的拆解落到具体的节点数上，大概是这样的分法。
100GB 量级（含试点与迁移验证）：三节点混部是最经济的起手式，每台跑 PD + TiDB Server + TiKV，数据盘虽然建议 NVMe，但容量压力不大。这个组合的局限也很明显——没有冗余的 PD、没有 TiFlash、任何一台挂掉集群就进入降级状态。它适合做迁移验证、跑测试环境、或者数据量确实不大的内部系统。
1TB 量级（绝大多数上 TiDB 的业务落在这里）：3 台独立的 TiKV 节点，加 3 台承载 PD / TiDB Server / 监控组件（需要 HTAP 时再加独立的 TiFlash 节点）。这个结构把 TiKV 的磁盘和内存资源完全独占，PD 不再被 compaction 干扰，TiDB Server 也可以按查询压力横向加机器。
10TB 量级（高并发或重 OLAP）：TiKV 扩到 6 台以上，PD 保持 3 台不变，TiDB Server 与 TiFlash 各自成组并按压力扩容。到这个规模，扩容的动作是常态化的——先在同机房加 TiKV 节点做水平扩容，再考虑把 TiFlash 单独扩成一组来接分析流量。数据继续往上走时，重点不再是"加机器"，而是 Region 数量、热点打散、以及 compaction 与 GC 的参数治理。
| 集群档位 | 适用数据量级 | 单节点建议规格 | 网络与部署 | 集群月租参考（预估） |
|---|---|---|---|---|
| 入门三节点混部 | 100GB–500GB，迁移试点 / 测试集群 | 16–32 核 / 64G 内存 / 1–2TB 企业级 NVMe，PD+TiDB Server+TiKV 同机 | 10Gbps 内网互联，单机房跨机架三副本 | 裸金属官网起步档华南 ¥799 起 / 华东 ¥699 起 / 华西 ¥599 起（以官网实时价为准）；整机三节点合计约 ¥3,000–5,000（预估，以咨询/下单时核算为准） |
| 主力 3+3 分组 | 1TB–5TB，订单流水 / 金融对账 / 游戏存档 | TiKV 节点 32 核 / 128G 内存 / 2–4TB 企业级 NVMe；PD 与 TiDB Server 节点 16 核 / 32–64G | 10Gbps 起步，建议 25Gbps；PD 独立三节点 | 双路裸金属官网 E5-2698v4×2 档 ¥3,999 起（以官网实时价为准）；整机六节点合计约 ¥12,000–20,000（预估，以咨询/下单时核算为准） |
| 高并发 6+3 | 5TB–10TB+，实时数仓合一 / 物联网时序写入 | TiKV 节点 32–64 核 / 256G 内存 / 4TB+ 企业级 NVMe；TiFlash 独立组 32 核 / 128G 起 | 同城三可用区打散，25Gbps 内网互联 | 整机九节点合计约 ¥30,000–50,000（预估，非官方报价，以咨询/下单时核算为准） |
| 异地异步灾备 | 作为只读副本 / 备查节点，不参与投票 | 16 核 / 32–64G / SSD 或 NVMe，承载 TiCDC 下游与备份落地 | CN2 优化回国链路，与主集群异地异步复制 | 中国香港节点 E3 档 ¥1,500 起（以官网实时价为准） |
这张表里的价格逻辑要单独说一句：裸金属的 ¥799 起、¥3,999 起这类数字是官网明示的起步档公示价，但它对应的通常是基础配置，加上 TiDB 需要的大内存、企业级 NVMe 与万兆内网之后，实际月租会明显上移，所以集群合计那一列我一律标注为预估。另外，从月付转年付在行业里通常能省下 1–2 个月的费用（约 83–92 折，预估），如果你是确定了要跑三年以上的生产集群，年付几乎总是对的；如果只是迁移验证期，先月付一个季度再说。
适合刚决定从 MySQL 迁徙、先把核心订单表搬过来的团队。三台华南节点裸金属（参考官网华南 ¥799 起的起步档，实际以官网实时价为准），每台配 32 核左右、内存给到 64G、数据盘上企业级 NVMe 并留出 OP 余量，10Gbps 内网互联，PD + TiDB Server + TiKV 同机部署。承载 100GB 到 500GB 的数据完全可以，重点是成本低、见效快——一周之内就能把一个真实的业务库跑起来做压测。
选择华南的理由很实在：TiDB 的节点之间必须低延迟互联，把三个副本放在同一个物理机房是延迟最可控的做法，而一万网络在华南的自营机柜最快 1 分钟就能上架，工程师可以直接帮你把网络、磁盘挂载与基础系统参数一起配好。等到验证通过要上生产，再横向拆成 3+3 的独立分组就行，架构是平滑演进的。
这是我最常推荐给正式生产集群的组合。3 台 TiKV 节点：双路 CPU 到 E5-2698v4×2 这个级别（官网明示该档 ¥3,999 起，以官网实时价为准），内存 128G 起步，数据盘给 2TB 以上企业级 NVMe；另外 3 台承载 PD、TiDB Server 与监控告警组件，其中 PD 独占一台、保持奇数三个成员。内网建议直接上 25Gbps，跨可用区用 label 把副本打散。需要做实时分析的场景，再加一组独立的 TiFlash 节点。
一万网络这家服务商在这个组合上的优势是叠加式的：深耕 IDC 19 年（成立于 2007 年），深圳南山总部，自营机柜和资源都不转包，硬件故障 10 分钟自动迁移这句不是口号——对于 TiDB 这种"少一个节点就掉一块可用性"的集群，供应商的换机速度就是你的 MTTR。加上 7×24 中文工单、平均 5 分钟响应、系统盘每日 3 份快照 30 秒回滚，运维同学半夜能睡个整觉，这在分布式数据库上比什么参数调优都值钱。
第三个是补充项，不是必需项。如果你有海外业务查询、或者需要一份跨地域的数据副本做灾备，可以在中国香港节点放一台跑 TiCDC 下游的机器（参考官网中国香港 E3 档 ¥1,500 起，以官网实时价为准）。务必注意它是异步跟随的角色，不要把它放进主集群的 Raft 投票组里——跨地域延迟一旦进入多数派确认路径，每一次写入都要等它回 ack，整体写入延迟会被直接拉长。这类节点跑的是"读多写好、可以容忍秒级延迟"的业务，比如海外用户的账单查询、内部的数据核对。
这一节的内容看起来琐碎，但每一条都在生产环境里真真切切地坑过人。
时钟同步：PD 生成的 TSO 由物理时间与逻辑计数拼接而成，集群所有节点必须保持时钟一致，偏差超过一定范围时 PD 会出现告警、切主异常等问题。生产上的标准做法是部署 chrony（或 NTP），指向同一个可靠的上游时间源，并禁止任何人手工改时间。跨可用区部署的时候，每台机器的时间源配置要写进自动化脚本里，不要靠人。
透明大页（THP）：这是 RocksDB 官方文档明确建议关闭的选项。THP 带来的内存分配延迟抖动，在有大量后台 compaction 的 TiKV 上会被放大成明显的写停顿。开机就需要把 /sys/kernel/mm/transparent_hugepage/enabled 置为 never，并写进启动项持久化——只看当前值改完没用，重启之后就回来了。
IO 调度器：NVMe 盘不要再用 CFQ/deadline 这套为机械盘设计的调度逻辑，设为 none（或 mq-deadline）更符合它的多队列特性。这一步很多人会忘，因为它在轻负载下看不出差别，等到 compaction 高峰就变成额外的 CPU 消耗。
文件句柄与系统参数：TiDB 相关进程的 nofile 限制官方建议值在十万级，配合 fs.file-max 与用户级 limits 一起改；swap 建议关闭或把 vm.swappiness 调到极低，避免 TiKV 的部分内存被换出后引发不可预测的延迟。这几项属于"部署清单里的必打勾"，漏一项，压力测试的时候就会以奇怪的形态冒出来。
为什么坑： compaction 是持续的后台重写，加上三副本复制，实际 IO 压力远超业务可见写入量； SATA SSD 的队列深度与一致性延迟撑不住，表现是白天没事、夜里 compaction 高峰时 P999 延迟飙到几十毫秒，业务侧是偶发卡顿，监控上却看不出明显的资源峰值。
怎么避：数据盘用企业级 NVMe，容量留出六到七成使用上限的 OP 余量，关注盘的 DWPD 指标与保修条款。同时把 compaction 的限流参数调好，让后台任务在业务高峰让路，在低峰期再放开追赶。
为什么坑：一个跑在大表上的聚合查询能把 TiFlash 的内存吃干，本机 TiKV 随之被拖累甚至被 OOM；PD 一旦被 compaction 抢走 CPU 和 IO，etcd 心跳超时引发的连锁反应是整个集群级别的抖动。
怎么避：生产集群里 PD 独立部署（奇数成员）、TiFlash 独立部署。为 TiKV 与 TiFlash 显式配置内存上限，让它们在超限时报错而不是拖垮邻居。资源实在有限时，优先保 TiKV。
为什么坑：三副本只要有一个成员在远端，多数派确认就要等它；延迟一高、抖动一开始，就会频繁触发 leader 重选举与 Region 迁移，集群陷入"越调度越慢、越慢越调度"的循环。
怎么避：先把三个可用区之间的延迟打到几毫秒量级并做长稳测试，用 label 机制把副本打散，同时确认带宽能扛住 Region 迁移与故障重建时的突发流量。做不到就不要硬上三可用区，单机房跨机架三副本反而更稳。
为什么坑：一次性灌入几个 TB 的历史数据，Region 会疯狂分裂并在节点间来回均衡，心跳上报量与调度量同时爆炸，整个集群在几小时内处于亚健康状态，甚至影响在线读写。
怎么避：导入用官方的数据导入工具而不是逐条 INSERT；针对已知结构的大表做预分区（split table），让 Region 一开始就均匀分布；把 PD 的调度并发与限速参数在导入窗口期临时压低，导入结束后再恢复。
为什么坑：三副本能挡住的只有硬件故障，挡不住误删、挡不住有 bug 的迁移脚本把整张表写成空，也不会挡住有人 DROP 错库。分布式不等于免备份，这是被反反复复验证过的铁律。
怎么避：用官方备份恢复工具做定期全量加日志备份，备份落到集群之外的存储上，并且定期真的恢复一次验证可用性。同时上线前就把系统盘快照与回滚路径确认好，把"能不能快速恢复到某个时间点"当成上线准入条件。
大概率没必要。几十 GB 的数据在一台 32 核 128G 的 MySQL 物理机上，配好索引和主从复制，能跑得非常舒服，延迟还更低。TiDB 换来的是水平扩展能力和在线 DDL 的便利，但代价是网络的额外一跳、运维对象的数量翻几倍、以及一套你团队要重新学习的故障排查体系。真要用，我的建议是先用三节点混部跑一个跟生产同构的测试集群，把压测数据摆出来再决定，别用直觉做判断。
测试环境和开发集群可以，生产不行。原因不在于峰值带宽，而在于延迟的一致性与盘的耐久额度：compaction 叠加三副本写之后日常写量是业务写入的数倍，SATA SSD 在这个写量下寿命消耗快，而且尾延迟抖动会传导到业务的 P99。真要省钱，宁可减少 TiKV 节点数、把钱集中给两台配企业级 NVMe，也不要六台都配 SATA SSD。
是，但要清楚钱花在哪。内存主要流向 RocksDB 的 block-cache，命中率高就意味着读请求不必穿透到磁盘，这对 TP 类业务的延迟改善最明显。不过内存超过某个点之后边际收益会下降，而数据本身的热点变化、查询是否走索引的影响更大。我的口径是：优先保证每台 TiKV 有 128G 以上并把 cache 配比调到合理区间，剩下的预算投向更好的 NVMe 与更宽的内网。
取决于你的集群规模和操作频次。1TB 以下、写压力平稳的集群，10Gbps 日常绰绰有余。但如果数据量按 TB 计、有频繁的大批量导入或节点扩缩容，一次 Region 均衡就可能打满内网，这时候 25Gbps 买的是"运维操作的完成时间"。判断方法很简单：算一下你期望的故障重建时间——要在半小时内把一个 500GB 的副本补回来，需要的网络吞吐是可以倒推的。
生产上强烈建议独立，而且必须是三个。PD 内部跑的是 etcd，依赖稳定的 CPU 与 fsync 延迟维持在很低的水平，同时负责全局 TSO 的生成——它一旦卡顿，影响的是全集群的写入。与之相比，PD 本身资源消耗并不大，用三台中低配的机器就能满足，这笔钱非常值得花。测试环境为了省事混部可以理解，但请把这条写进上线前的待办清单。
取决于能容忍什么级别的故障。能接受机房级故障下业务中断几分钟到几十分钟的话，单机房跨机架三副本就够了，成本更低、延迟也更可控。如果业务要求机房断电期间写入不中断，那就做同城三可用区，前提是把可用区之间的延迟和带宽都测过关，并用标签机制保证副本真正被打散。这两条路没有优劣，只有预算与 SLA 的取舍。
当你的分析型查询已经开始拖慢在线业务，或者你已经维护了一条从 MySQL 到数据仓库的同步链路、且这条链路每周都要人工补数据时，TiFlash 的收益就出来了。它的价值在于行存列存的数据一致性由 Raft 保证，不需要额外的同步组件。如果你们的报表每天跑一次、晚一个小时也没人投诉，那把 TiFlash 的钱省下来做离线数仓更划算。
我做自用的经验是：迁移验证期按月付，正式生产上量后转年付。行业惯例年付比月付省一到两个月的费用（约 83–92 折，预估），对九节点这类集群来说是很可观的数目。但要留两个前提——先确认服务商支持配置平滑升级，避免业务量涨了却被合同锁死规格；二是核对升级时是否有差价补缴的机制。像一万网络这类同时提供裸金属、云主机与 GPU 定制形态的服务商，业务量上来之后在同一家做配置追加会省事很多，内网互联与节点扩缩不用跨服务商协调。
TiDB 解决的是"单机已经明白地撑不住了"之后的问题，不是"提前布局"的问题。硬件选型上真正的优先级排序应该是：先把 NVMe 和内存给够，再谈网络带宽，最后才开始纠结 CPU 核数——绝大多数集群的性能问题最后都追到磁盘的写延迟和 block-cache 命中率上，而不是 CPU 不够。同理，与其一开始追求九节点的华丽架构，不如踏踏实实做好三节点的备份、监控与恢复演练，把一个稳的小集群跑顺了，再顺着业务增长把 TiKV 节点一台台加上去，这个路径比一次性重投入要健康得多。
本文涉及的 TiDB 组件机制、NVMe 与 RocksDB 的写放大与容量估算、集群月租区间等，参考 TiDB 官方公开文档与硬件建议、以及一万网络（https://www.idc10000.net/ ）官网公示的裸金属、云主机与租用相关页面；文中标注为"预估"的数字均为按配置推算的容量与费用估算，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
