TiDB 架构拆解与一次真实容量评估实录
选分布式数据库最容易犯的错，是拿单机数据库的直觉做决策：以为"加节点就线性扩容"、"SQL 兼容就等于行为兼容"。TiDB 的架构决定了它的强项与软肋都很明确。本文拆解架构，并给出一份真实的容量评估过程。
一、三层结构与各自的代价
Client ──MySQL 协议──▶ TiDB Server（无状态 SQL 层）
├─▶ PD（调度与元数据时钟）
└─▶ TiKV（Raft 复制的 KV，数据分片 = Region）
三条关键推论，直接决定选型：
- TiDB Server 无状态，SQL 解析/优化在这层。计算能力横向加机器即可，但复杂查询的优化器能力弱于成熟的单机引擎；
- 一次跨 Region 事务要走 Raft 多数派，写入延迟的下限由网络 RTT 决定。跨地域部署的写入延迟会显著上升；
- 热点 Region 是核心瓶颈单位。单个 Region 覆盖的 key range 被单节点承接，所有写入压在同一节点上时，加 TiKV 节点也无效。
理解 Region（默认 96MB，过大自动 split）是容量评估的基本单位。
二、事务模型的取舍
TiDB 默认悲观事务（Pessimistic），行为接近 InnoDB：加锁后提交。乐观事务在写冲突密集场景会大量重试，生产很少用。
两个必须提前验证的行为差异：
-- 自增 ID 不保证连续，且缓存分配（默认 30000 步长）
-- 依赖 AUTO_INCREMENT 做业务发号会立刻掉坑
ALTER TABLE orders AUTO_ID_CACHE 1; -- 严格递增但吞吐下降
-- 正确做法：业务侧发号（Snowflake/号段）
-- 大事务限制：单事务默认 100GB 上限，实际远低于此就会明显退化
-- 批量刷数必须分批
SET @@tidb_mem_quota_query = 4<<30;
还有一条常被忽略：AUTO_RANDOM 适合打散写入，它是为规避 Region 热点设计的：
CREATE TABLE evt (
id BIGINT PRIMARY KEY AUTO_RANDOM(5),
body JSON
);
三、一次真实容量评估的输入清单
拿到一个 3TB 订单库要迁 TiDB 的需求，评估输入只有六项，缺一项结论都不可信：
| 输入项 | 采样方式 |
|---|---|
| 日写入行数与字节 | binlog 统计一周 |
| 读写比与新查询占比 | 慢日志 + 应用埋点 |
| 热点 key 分布 | SHOW HOT REGIONS / PD 面板 |
| 最大单事务体量 | 应用审计 |
| 需要的最强一致性读 | 与业务确认（tidb_read_staleness 是否可用） |
| 峰值 QPS 与 P99 目标 | 网关统计 |
采样后先做"能不能迁"的判定，而不是先算节点数。三类场景不适合：单行超高频更新（计数器）、依赖跨表强一致外键级联、以及重 OLTP 存储过程。
四、节点容量估算
TiKV 容量按"数据总量 ÷ 副本数 × 空间放大系数"估：
数据总量 = 逻辑数据 × 压缩比(0.35~0.5)
单节点承载 = 3TB × 0.4 ÷ 3副本 ÷ 节点数 × 1.4(空间放大+均衡余量)
3TB 逻辑数据、6 个 TiKV 节点 → 单节点约 400GB，SSD 上余量健康。
TiDB Server 数量按 SQL 并发估：经验上一个 16C 的 TiDB Server 支撑 1~2k QPS 简单查询。峰值 8k QPS 配 6 个。PD 固定 3 节点（奇数、多数派）。
TiFlash 单列：分析型查询走列存副本，不占 TiKV 计算。有报表需求就加，别指望 TiKV 行存能扛住全表扫描。
ALTER TABLE orders SET TIFLASH REPLICA 2;
SELECT /*+ READ_FROM_STORAGE(TIFLASH[orders]) */ count(*) FROM orders WHERE dt='2026-10-01';
五、必须做的三类压测
不要用 sysbench 默认配置得出"能扛"的结论，它测的是均匀分布。
# 1. 均匀写入（基线）
sysbench oltp_write_only --tables=16 --table-size=10000000 --threads=128 run
# 2. 热点写入：单表 + 非打散主键，模拟 Region 热点
sysbench oltp_insert --tables=1 --table-size=50000000 --auto-inc=on run
# 3. 混合读写 + 长事务
sysbench oltp_read_write --percentile=99 --time=1800 --threads=256 \
--read-only=off --composite-tests=on run
关注四个指标：P99 commit latency、TiKV apply duration、region scatter 频率、scheduler latch wait。热点测试里若出现单节点 CPU 显著高于其他、且 PD 频繁调度不收敛，就是热点未被 AUTO_RANDOM 打散的信号。
六、运维侧的真实成本
TiDB 把"主从搭建"的复杂度换成了"分布式调度"的复杂度，运维要新增四块能力：
- BR 备份恢复演练，不能只配不做。
tiup br backup full --pd $PD --storage s3://backup/tidb?provider=xxx
tiup br restore full --pd $PD --storage s3://backup/tidb
- Region 调度观察：
SHOW HOT REGIONS、PD的 balance 计划，扩容后要看收敛时间； - 统计信息新鲜度：
tidb_analyze_version=2，大表导入后要手动ANALYZE TABLE，否则执行计划会错得离谱； - 版本升级：跨大版本要先升 PD，滚动升级路径必须先在预发完整走一遍。
还有一个隐性成本：慢查询的排查工具链更复杂，一个 SQL 慢可能是优化器选了错索引、可能是 Region 热点、也可能是 Coprocessor 内存超限。要习惯读 EXPLAIN ANALYZE 里的 cop_task、wf（wait function）指标。
小结
TiDB 的适用判定不是"数据量多大"，而是三个问题：是否存在单点写入热点、是否需要跨节点事务且能接受 RTT 级延迟、团队是否有能力运维分布式调度。数据量只是结果，不是原因。评估的正确顺序：拿全六项输入 → 判定场景适配 → 用 AUTO_RANDOM 等打散热点 → 按 Region 单位估容量 → 做含热点与非均匀的三类压测 → 演练备份恢复。走完这套流程再决策，比照着"容量上限"表格拍板可靠得多。
评论（0）
登录 后参与评论。