TiDB 考证：一篇把身世、架构与十大误解讲清楚的文章

一、为什么值得"考证"TiDB

只要你搜"分布式数据库""MySQL 替代品"，TiDB 一定在结果前排。它 GitHub Star 37k+，长期稳居国产数据库前三，金融、互联网、政务都有大规模落地。

但越是"耳熟能详"，越容易积累误解："TiDB 就是开源版 MySQL""它是 NewSQL 鼻祖""换上去零改造"——这些说法，要么以偏概全，要么干脆是错的。

这篇文章想做一件事：把 TiDB 的来龙去脉和技术边界考证清楚，让你在选型、面试、写方案时，能说出"为什么"，而不是"大家都这么说"。

二、身世考证：TiDB 到底从哪来

1. 三个人的公司，和一个仓库

TiDB 由 PingCAP 发起。公司 2015 年成立，三位联合创始人分别是 刘奇（Max Liu，CEO）、黄东旭（Ed Huang，CTO）、崔秋。

公开时间线是这样的：

• 2015 年 9 月：TiDB 的 GitHub 仓库第一次提交。

• 2016 年：正式开源（Apache 2.0 协议）。

• 2017 年 10 月 16 日：TiDB 1.0 GA——距第一个 commit 约 771 天，彼时已在亚太 30 多家公司生产环境运行。

2. 思想来源：四篇论文，一个拼图

TiDB 不是凭空发明的，它的骨架能清晰拆出四个来源：

这里有个关键考证点：Spanner 用的是 GPS + 原子钟（TrueTime），PingCAP 买不起这套硬件。于是他们没有"硬抄"，而是用一个中心化的 Placement Driver（PD）当时间戳预言机（TSO）——每次事务找 PD 要一个全局单调递增的时间戳。这是一个"平民化妥协"，也是 TiDB 架构里最容易被忽略、却又最影响性能的特征（后文会展开）。

3. 一个被低估的赌注：TiKV 用 Rust 写

TiKV（存储层）是用 Rust 写的，而 TiDB（SQL 层）用 Go。2015 年 Rust 才稳定一年，几乎没人敢在生产系统里用它。PingCAP 为什么敢？

理由很硬：TiKV 底层要用 RocksDB（C++ 写的 LSM-Tree 存储引擎）。Go 要调 C++ 得走 Cgo，对一个每秒上千次调用存储引擎的数据库来说，Cgo 开销不可接受；C++ 又容易写出"静默损坏数据"的底层 bug（悬垂指针、数据竞争）。Rust 在编译期保证内存安全、性能接近 C++、且没有 Cgo 包袱——成了唯一同时满足所有约束的选择。

附带一个意外收获：西方工程师因为"想给 Rust 项目贡献代码"而涌入 TiKV，反而让这个中国数据库项目拿到了一批国际化贡献者。

名字彩蛋：Ti = Titanium（钛），取"稳定、轻盈、强韧"之意；DB = Database。不是什么缩写黑话。

三、架构考证：四件套到底怎么分工

TiDB 的核心设计哲学是计算与存储分离、各组件独立扩缩。一套最小生产集群由这四部分组成：

• TiDB Server：无状态，不存数据，可以起多个实例做负载均衡。它只负责"把 SQL 翻译成对存储层的调用"。

• TiKV：真正的存储。数据按 Region（一段连续的 Key Range，默认约 96MB，超阈值自动分裂）分布；每个 Region 三副本，Raft 保证一致；底层是 RocksDB。

• PD（Placement Driver）：集群"大脑"，存元数据、下发调度命令、分配全局时间戳 TSO、提供 Dashboard。自身也是 3 节点高可用。

• TiFlash：特殊存储节点，数据以列式存储，给分析查询加速（详见第五节 HTAP）。

关键边界：TiKV 对外暴露的是 KV API，不是 SQL。SQL 语义全部由无状态的 TiDB 层承担——这正是它能水平扩展、又能兼容 MySQL 协议的底层原因。

四、事务考证：Percolator 与"乐观/悲观"

TiDB 的事务模型直接继承自 Google Percolator：

• 事务开始时从 PD 取一个全局读时间戳；提交时取一个提交时间戳；靠时间戳排序确定事务先后。

• 默认隔离级别是 Repeatable Read（可重复读），靠 MVCC（多版本并发控制）实现——每次更新都产生新版本而非原地覆盖，旧版本由后台 GC 定期清理。

• 支持乐观事务和悲观事务两种模式。早期默认乐观（提交时才检测冲突，冲突要应用层重试）；为了贴近 MySQL 的锁体验，后来默认改成悲观事务。

考证提醒：TiDB 的"可重复读"与 MySQL InnoDB 的"可重复读"在边界细节上并不完全一致（例如对某些写偏斜的处理），不能想当然等同。

五、兼容性考证：它是不是"MySQL 替代品"

这是误解最重的地方，必须拆开两层看：

第一层：协议兼容是真的。 TiDB 实现了 MySQL 的网络协议和大部分语法，MyBatis、JPA、MySQL 客户端基本能直接连，迁移成本确实低。官方也明确：兼容 MySQL 5.7 / 8.0。

第二层：引擎相同是假的。 TiDB 没有 InnoDB，它没有单机存储引擎那套行为。这意味着：

• 存储引擎相关的特性、部分 Optimizer Hint、个别函数表现会不同；

• 外键直到 v6.6.0（2023 年） 才支持，此前长期是"兼容性短板"；

• 不能假设 100% 原地替换（drop-in）。官方自己在文档里也写了 "It is not MySQL/InnoDB"。

还有一个实战级坑：自增主键（AUTO_INCREMENT）是单调递增的，会导致所有写入都砸向最后一个 Region，形成写入热点，把水平扩展的优势直接废掉。官方解法是改用 AUTO_RANDOM 或 SHARD_ROW_ID_BITS。这条不考证清楚，上线即踩雷。

六、HTAP 考证：TiFlash 是不是"真·HTAP"

HTAP = 同一套系统同时跑事务（TP）和分析（AP）。TiDB 的做法是物理隔离路线：

• TiFlash 是独立的列存节点，通过 Raft Learner 机制从 TiKV 实时异步同步数据（不影响行存写入链路）；

• SQL 优化器基于代价，自动决定查询走行存、列存，还是行列混合；

• 分析查询跑在独立节点上，不会拖慢交易。

代价也很直白：给表加 TiFlash 副本，存储 footprint 直接翻倍，而且要额外机器。所以正确姿势是——只给真正跑分析查询的表加列存副本，别"全表都加"。

对比之下，OceanBase 走的是"同一集群内逻辑隔离"的 HTAP（基线列存 + 增量行存），部署简单但极端混合负载下可能有资源争抢。两种路线没有绝对优劣，只有场景适配。

七、演化脉络：从 1.0 到 8.5，以及一个信任插曲

版本时间线（节选）

• 1.0（2017.10）：首个 GA。

• 4.0（2020.05）：引入 TiFlash、TiDB Dashboard，HTAP 成型。

• 5.0 / 6.0 / 7.0：资源管控、性能、稳定性持续迭代；7.5 LTS 成为长期维护线。

• 8.5 LTS（2024.12.19）：当前推荐的新部署长期支持版，截至 2026.04 已迭代到 8.5.6；9.0 为开发预览（beta）。

• 保守生产环境仍可跟踪 7.5 LTS 乃至 6.5 LTS。

⚠️ 选型铁律：生产环境务必选 LTS（长期支持版），不要上非 LTS / beta。只有 LTS 线才持续发补丁。

一个不得不提的插曲：Jepsen（2019）

分布式系统圈有个"照妖镜"叫 Jepsen（Kyle Kingsbury 做的正确性测试），曾让一堆声称强一致的数据库翻车。2019 年它对 TiDB 2.1.7 出报告，结论很严肃：存在丢失更新（lost updates）、读偏斜（read skew），以及两套盲重试机制在冲突时重复应用更新。

PingCAP 的反应是关键看点：他们没有公关淡化，而是公开详细技术回应、把每一个问题都修掉。在"信任靠透明"的数据库工程圈，这次"把失败完全认下"反而成了品格证明——很多工程师因此从不信任转为长期拥护。

这件事本身，就是考证 TiDB 时最该记住的一课：一个项目靠不靠谱，不看它宣称多强，看它出事时怎么认、怎么改。

云与 AI 的新方向

• TiDB Cloud：托管服务，分 Serverless（Starter，免费额度内零成本）、Essential、Dedicated、Premium 多档；支持 AWS / Azure / 阿里云。

• 向量能力（v8.4+）：原生 VECTOR 类型 + 余弦/L2 距离函数 + 基于 TiFlash 的 HNSW 向量索引，可把 Embedding 和关系数据存同一库，省掉独立向量库，直接服务 RAG。

• 平凯数据库：PingCAP 中国实体（平凯星辰）推出的 TiDB 企业版，含物理复制、XML 类型、向量/全文检索等增强。

八、十大常见误解辨析（清单）

1. "TiDB = 开源 MySQL" —— 错。协议兼容，但无 InnoDB，引擎行为不同。

1. "换上去零改造" —— 半对。大部分应用能直接连，但存储引擎特性、个别函数、热点自增主键要处理。

1. "TiKV 是 TiDB 的一部分" —— 准确说 TiKV 是独立项目，曾是 CNCF 孵化项目（2018 年 8 月接纳），可单独当分布式 KV 用。

1. "它有原子钟/TrueTime" —— 没有。用 PD 的 TSO 中心时间戳替代，省了硬件但引入了中心依赖。

1. "HTAP 免费送" —— 物理隔离方案，加 TiFlash 副本=存储翻倍+额外节点，按需添加。

1. "自增主键没问题" —— 会写入热点，用 AUTO_RANDOM / SHARD_ROW_ID_BITS。

1. "三个进程就能跑" —— 生产最小集是 PD(3) + TiKV(3+) + TiDB(2+)，低于 3 个 TiKV 副本数兜底不了。

1. "TSO 无所谓" —— 高并发下 TSO 是协调点，跨地域 PD 延迟直接加到事务延迟上，PD 要离 TiDB 近。

1. "乐观/悲观随便" —— 默认已改悲观（贴近 MySQL）；乐观模式提交期可能抛写冲突错误，应用要能重试。

1. "版本随便选" —— 生产只上 LTS（如 8.5.x），beta/开发版只评估。

九、结语：TiDB 是什么，不是什么

考证到最后，可以给一句话定义：

TiDB 是一个受 Google Spanner/F1/Percolator 启发、用"无状态 SQL 层 + 分布式 KV 存储 + 中心化调度"实现 MySQL 协议兼容与水平扩展的开源 NewSQL/HTAP 数据库。

它是解决"单机 MySQL 遇到分库分表天花板"的工程答案，不是 MySQL 的克隆；它是靠透明修复 Jepsen 问题建立信任的开源项目，不是靠话术包装的产品；它在 HTAP、云原生、AI 向量检索上持续进化，但每个能力都有明确的代价与边界。

选型时记住一句大实话：没有"最好的数据库"，只有"最贴合你场景的数据库"。TiDB 适合"想摆脱分库分表、又要 MySQL 生态、还要顺手做实时分析"的团队；如果你的核心是 Oracle 存量存储过程、或者极度追求单机小事务延迟，那另一条路（如 OceanBase）可能更对。

把这篇文章里的时间线、边界和那十个误解带走，比背一百句"国产之光"都管用。