十年再出发：回顾我与 TiDB 的成长之旅

唐刘 · 发表于 3 天前

我们却觉得反而很放心，为什么？因为这种透明反而让客户更加信任我们。

客户能直接看到我们是怎么工作的，bug 是怎么发现又怎么修复的，产品是怎么一步步成长起来的。事实也证明，这种透明度反而为我们赢得了巨大的客户信任，甚至比那些刻意隐瞒问题的企业更容易被客户所接受。

唐刘 · 发表于 3 天前

谈到 TiDB 最初的起点，那就是“解决分库分表（sharding）的痛苦”。

作为互联网行业出身的程序员，我们深受 MySQL 分库分表的折磨，每次修改表结构都要折腾到半夜，痛苦到怀疑人生。

于是，我们希望：搞一个真正能无限扩展（Scalable）的分布式数据库，彻底终结程序员的 sharding 噩梦。

这个想法最初特别朴素：我们只是想解决自己的痛点。但后来发现，这种纯粹的初心，竟然成了 TiDB 的核心竞争力，也成了众多客户选择我们的重要原因之一。

唐刘 · 发表于 3 天前

回想起来，我们几个人当时并没有任何数据库开发经验。我们只是数据库的重度使用者，根本没碰过数据库源码，更别说开发一个新的分布式数据库。

为什么我们敢这么干？只能说，有时候无知反而是一种优势，俗话说得好，“不知者无畏”。

唐刘 · 发表于 3 天前

正是带着这种无知者的勇气，我们踏上了 TiDB 这场充满未知的冒险之旅。

而我，也因为当时一时脑热，成了 PingCAP 的第一个正式员工，并从此开启了我此后长达十年的 TiDB 开发旅程。

多年以后，我回想起当时的决定，依然觉得庆幸和自豪。

唐刘 · 发表于 3 天前

正是带着这种无知者的勇气，我们踏上了 TiDB 这场充满未知的冒险之旅。

而我，也因为当时一时脑热，成了 PingCAP 的第一个正式员工，并从此开启了我此后长达十年的 TiDB 开发旅程。

多年以后，我回想起当时的决定，依然觉得庆幸和自豪。

唐刘 · 发表于 3 天前

二：技术驱动的幸福时刻
做产品什么时候最爽？做技术的总喜欢问一个很哲学的问题：“写代码的哪个阶段最快乐？”

可能每个人都有自己的答案，但对我来说，答案非常简单：产品还没给客户用的时候，那段时光最幸福。

没错，客户没进门之前，程序员只需要安心写代码，完全不用操心客户的抱怨、需求、紧急电话，更不用半夜爬起来救火。那是一种纯粹的技术快乐，专注于代码本身的乐趣。

但问题在于，做产品最终还是要给客户用的，这快乐的时光，注定无法长久。

唐刘 · 发表于 3 天前

TiDB 的开发一开始就让人觉得是件很疯狂的事情——毕竟，一个数据库不是说写就能写出来的。

不过我们也不是毫无准备，毕竟这世上早有 Google 发过论文，比如 Spanner。除了论文，还有比我们早一年创办的 CockroachDB（俗称“蟑螂数据库”）和经典的 HBase 都给了我们很多启发。

程序员造轮子并不可耻，但如果闭着眼睛瞎造就挺蠢的。我们理智地站在这些巨人的肩膀上，借鉴了大量已经验证过的架构设计思想。

唐刘 · 发表于 3 天前

造数据库第一步就是挑选语言。我们毫不犹豫地选了Go。

为什么？因为我们几个人最熟悉、最喜欢的语言就是Go。程序员都明白一个道理：在未知领域里闯荡，最安全的选择永远是自己熟悉的语言。

我们的策略也很简单粗暴：先让程序跑起来再说。

唐刘 · 发表于 3 天前

早期，我们决定兼容 MySQL 语法。这个决定直接奠定了日后 TiDB 成为最佳 MySQL 替代方案的基础。

然而，这个决定背后的坑之深，远超我们的想象：
1.MySQL各种奇葩语法坑；
2.稀奇古怪的兼容性问题；

只能说，MySQL 兼容是一把双刃剑，但总体而言，好处还是大于坏处。

唐刘 · 发表于 3 天前

虽然今天 TiDB 已经有很先进的优化器和执行引擎，但当年我们完全没有优化器相关的知识，也没有人做过数据库优化器开发。

怎么办？我们只能祭出程序员的万能法则：“不懂就先写个最简单的”，于是搞了个 rule-based 优化器，简单到让人难以置信。执行引擎就更直接了，我们直接用了最经典的 Volcano 模型，也就是“火山模型”，一层一层往下next调用，简单有效。

正是这种“无知者无畏”的简单策略，让我们迅速做出了第一个可用的版本。