TiDB是PingCAP公司开源的分布式NewSQL数据库，它兼容MySQL协议，同时具备水平扩展能力与强一致性事务支持。在真正落地一套生产级集群之前，服务器与集群拓扑的规划直接决定了后续性能上限和运维复杂度。很多团队在初期低估了PD调度对网络的要求，或者把TiKV和TiDB混部在同一批机器上，结果在写入高峰时出现leader频繁迁移和延迟陡增。
理解TiDB的架构角色是规划的前提。整套系统主要由三类核心组件构成：TiDB Server负责无状态SQL解析与计算，TiKV Server承担底层键值存储与副本管理，PD Server作为全局调度中枢维护元数据并分配Region。此外还有可选的TiFlash列存节点，用于加速分析型查询。由于TiDB Server本身不存数据，它可以随业务并发量随意增减；而TiKV是有状态节点，其机器数量与磁盘规格决定了集群的总容量与吞吐底线。
在PingCAP官方建议中，生产环境至少部署3个PD节点以保证元数据高可用，TiKV也必须3副本起步。如果业务只是测试验证，可以用单台多实例方式模拟，但生产集群绝不可将PD与TiKV放在同一块机械盘上争抢IO。实际规划时，应先梳理业务模型：是写多读少、还是读多写少，是否涉及大事务或热点更新，这些都会改变节点比例的取舍。
节点角色与服务器配置划分
TiDB Server属于计算密集型但无状态，推荐采用中等规格服务器，例如16核32G内存即可承载较高并发连接。因为它不落盘数据，本地磁盘仅用于临时排序和日志，使用普通SSD就足够。多个TiDB节点前面通过LVS或HAProxy做负载均衡，任意一个宕机都不会影响整体服务，因此这类节点适合部署在相对廉价的通用云主机上。
TiKV Server是存储与吞吐的核心，必须使用高主频CPU、大内存和高速NVMe SSD。每个TiKV实例建议独占一块盘，避免与系统盘混用。官方经验值是每TB数据预留3倍空间以应对副本与Compaction膨胀，同时内存配置应为单机数据量的约10%到15%，否则缓存命中率下降会拖累查询。PD节点资源消耗不大，但对延迟极敏感，应与TiKV分开部署并保障低延迟网络。
当业务存在实时分析需求时，可引入TiFlash节点。TiFlash以列式存储异步同步TiKV数据，适合复杂聚合。它不计入行存副本数，但会额外占用计算和磁盘。规划阶段要根据AP查询占比决定是否独立部署，若OLAP只是偶尔发生，可暂不采购TiFlash，后续再横向扩展。
容量估算与集群规模测算
容量规划不能只盯着原始数据大小。以一张日均写入五千万行的订单表为例，行存加索引在TiKV中通常有1.5到2倍膨胀，再乘3副本，实际占用是原始量的4到6倍。假设单行平均500字节，一年数据原始量约7.3TB，集群裸容量就需准备30TB以上NVMe空间。若还启用TTL或历史归档，可在PD中配置合并策略降低常驻量。
除了空间，还要测算每秒读写峰值。TiKV单实例在NVMe上大致能稳定承担1到2万写QPS，读QPS依赖缓存可到5万以上。若业务峰值写达到10万QPS，至少需6到8个TiKV实例分流。TiDB Server则按连接数估算，每个节点支撑2000到3000活跃连接为宜。通过这种自底向上的模型，能算出最小节点数，再叠加容灾冗余得出采购清单。
下表给出一种常见中等业务规模的参考规划，实际请结合压测调整：
| 组件 | 节点数 | 单节点规格 | 用途说明 |
|---|---|---|---|
| TiDB | 3 | 16C32G SSD系统盘 | SQL计算入口，无状态 |
| PD | 3 | 4C8G 独立SSD | 元数据与调度 |
| TiKV | 6 | 32C128G NVMe 2TB | 行存与事务 |
| TiFlash | 2 | 32C64G NVMe 4TB | 列存分析 |
网络、机架与运维规划
分布式数据库对网络要求远高于单机库。PD与TiKV之间心跳和Region迁移频繁，建议使用万兆互联且延迟低于1毫秒的同机房网络。跨机架部署时应保证副本分散在不同机柜，防止交换机故障导致多数派丢失。若做两地三中心，需通过PD的location-label配置让Raft组天然跨可用区，否则默认调度可能把三个副本放同一机柜。
运维层面要提前规划监控与参数。TiDB自带Prometheus和Grafana面板，服务器应预留采集端口并配置告警阈值。系统参数方面，Linux透明大页必须关闭，NUMA绑核能提升TiKV约10%性能，磁盘调度算法选none或mq-deadline。这些在装机模板里固化，可避免后续逐台整改。备份则推荐BR工具直接落盘对象存储，不要走逻辑导出占用TiDB计算。
最后，集群规划不是一次性的。PingCAP的弹性扩缩容允许后续加节点，但提前留好IP段和机架位能减少reshuffle成本。建议每半年根据业务增速复盘一次容量曲线，在Region数量接近百万级前完成扩容，以免PD调度压力陡增。只有把角色、容量、网络三步串起来，TiDB集群才能真正发挥NewSQL的价值。
TiDBNewSQL数据库PingCAP集群规划修改时间：2026-08-16 13:16:34