作者： xfworld 原文来源：https://tidb.net/blog/3e6691a6

我和 tidb 的故事

每个人都会有自己的方向，或多或少都会受工作、生活、梦想等等的影响，甚至被左右，深陷其中不知如何选择

序章

我还在上一家公司效力的时候，还是一个资深的“攻城师”，当时公司内部大部分的数据库都是 oracle 和 sqlserver，遇到的业务场景大部分都是一个单库就搞掂了，对于业务要求高点的，集群的方式实现高可用和热备就足够了。当业务开始有爆炸性增长的时候，这样的方式就玩不转了，最明显的状态就是数据库的主库 CPU 和 磁盘都是高得不能在高了，完全没办法满足业务的要求，那这个时候肯定会问咋办呢？

当时最出名的就是 阿里开源的项目 Cobar，但是 Cobar 后面停更了（阿里的开源项目很容易这样子 ….），不过还有继任者 Mycat，当然给出的方案就是分表分库，当时我对这个处理方式觉得存在一些疑惑，决定深入了解一下，于是加入到了开发组，对于这个处理的方式了解得越深，就发现坑会越大 ….

1. 事务问题

2. 查询聚合的问题

3. 查询排序的问题

4. 分片不足需要扩容

5. 磁盘不够需要扩容

6. …..

ps: 当时为了解决排序和聚合的问题，开发组的大佬们还搞出了一个很强的方案，堆外小根堆排序 ….

带着这么多头疼的问题，时间进入到了微服务的时代，同时带动了 mysql 的流行，似乎一个服务实例挂接一个数据库实例的方式很合理，但是根本上未能解决扩容和资源上限的问题，带着这个问题继续前行，继续寻找

偶遇

时间飞逝，一下就到了 2019 年，突然发现有一个开源产品 tidb，带来很大的冲击，天生就是分布式的，能够很好的解决资源扩容和读写上限的问题，简直就是最佳答案 ：）刚好 tidb 社区当时要来武汉举办技术日的活动，必须报名参加；

tech day 2019

现场主持活动的就是三位大佬之一的 崔秋，聊了很多背景，受益良多

当时给我印象最深的是姚婷，分享了存储结构和算法，从 B-，B+ 到 LSM Tree，以及相关硬件发展的一个时间历程，带来的变化和挑战（这里比较遗憾，遗失了不少图片）

另外还遇到了 daocloud 的小伙伴，然后一起在聊这个产品，都认为这个对硬件资源要求好高，想要学习这个的投入会十分烧钱钱；

但是一致认为这个是未来最好的一个方向，会继续关注

前行

tidb 在分布式架构层面和工程模型，以及版本管理、发布方式无疑都是最佳实践

正是因为如此，就很像一个超级庞大的汉堡包摆着你面前，甚至都不知道怎么下口，很想每个地方都去咬一下，但是又没办法深入，这种痛苦来源于自己的知识广度和深度都不够，无法找到合适的一个方向，当我无脑寻找方向的时候，2020 年 tidb 开始建设开源社区，全方位为 tidb 建设整体的生态：

1. tidb 知识分类 -> 简单传递

2. 场景解决方案 -> 行业解决方案

3. 使用问题收集 -> 常见问题解答

4. 优化问题收集 -> 主线 / 支线 功能迭代

5. 体系认证建设 -> 深入传递

ps: 以上关于生态的归类和描述，纯属个人想法 ….

当年 4 月，毫不犹豫的注册进入社区后，发现社区有好多的深度资源，大佬们十分努力分享前期耕耘实践过的方案，分享的方案对于各种场景存在的痛点，和一些未来的期望，给人有更多更深的思考，大体的方向：

• 如果是你遇到这种痛点，没有更多的指引时，会怎么办？

• 如果资源不太充足的情况下，怎么能更好利用现有的资源来解决？

• 在解决问题的时候，会不会遗留什么坑？是否也会深度思考后续的一个方向？

实事上这些问题都会体现到技术点上：

1. 分布式协议和算法

2. OLTP 和 OLAP

3. 高并发

4. 高吞吐

5. 负载和调度

6. …..

当这些技术点慢慢汇聚在一起的时候，就慢慢演变了技术场景，然后需要对这些知识储备，以此来应对未来更多的变化变化会体现在两个点上：

1. 公司业务高速发展，需要更强的技术体系来支撑

2. 自己的路应该怎么走，在方向上应该选择更有把握的

写到这里，肯定会有人会问会说，人生苦短这么卷是干嘛？嫌自己不辛苦不够累么？若能找到努力的方向是件很庆幸的事情，何况是自己能立刻做的，还是能做好的，为嘛不做？做自己喜欢的事情，而且还能看见好的结果，还会觉得累么？

不找任何借口和理由，继续前行 ……

如果非要找一个理由，如图：

分享

在 asktug 找到方向后，通过学习行业实践的方案，慢慢掌握 tidb 能解决问题的思路，其实最想掌握的是 tidb 能帮我解决什么问题，通过什么方式可以更好的使用 ……

从架构 到 功能，从原理 到实践，在这个过程中其实也踩了不少坑，当时官方文档还只有 3.x 的版本，对于整个部署过程的难度还是有点高的，特别是部署的工作量，我自己用一台退役的笔记本，直接用虚拟机的方式，然后 ansible 方式搭建了 3.X 的 tidb 集群，操作起来问题也挺多的，当时搭好后，能跑起来，还是很有成就感的。没过多久 4.0 就发布了，还发布更加强大的部署工具 tiup，果断把 3.X 卸掉（当时还没有 ansible 转到 tiup 上的操作模式），装上了 4.0 体会了一下有 Dashboard 的感觉，很不错。

这个折腾的期间，asktug 上有好多的小伙伴，都在提各种问题，问题点我做了简单分类：

1. 官方文档上有介绍，但是不够详细 （补充说明）

2. 对于 tidb 架构不够了解，以单点数据库的视角来理解和操作，导致操作结果异常

3. 缺少相关的操作指引，不知道每步操作需要注意事项，出现操作问题时，怎么去处理相关的问题

4. 建库，建表对于字符集的处理方式，有大小写要求和明确区分

5. 建表对于性能要求和普通结构之间的差别 （不过 5.0 的诞生彻底解决了这个问题[聚簇索引]）

6. 关于性能优化，特别是 SQL 优化，问题定位都存在比较大的问题（特别是容易出现 OOM 的情况）

7. 对于复杂 SQL 可能无法按照 oracle 哪种方式来支持，需要从业务的层面需要进行不同层度的拆分满足业务需求

8. …..

以上其实还有很多很多，然后 CTC 的专家们也在进行解答。我发现我也能解答一部分问题，刚好可以巩固自己学的知识，也刚好总结一下经验能够分享给更多小伙伴，此项历练除了可以增加自己处理问题的能力，也可以收集更多的场景和一些常见的问题，帮助自己来沉淀这些经验，以此满足未来业务发展的要求，从而提炼出最佳实践

历练

PE 是 PingCAP Education 的简称， 当时还只有 3.X 版本的 tidb，所有官方的学习资料还属于内部服务，必须报名参加学习；当时很幸运了参加了一次 9.9 元的培训活动：【PCTA 的训练营】，当时自己苦于不知道怎么提升，毕竟 asktug 上分享的各种经验和资料十分零散，无法更好的掌握这个架构对于问题合适并且合理的处理过程；然后训练营对于每天学习都有很明确的目标。其实当时自己每天的工作也很饱和，但是觉得这个架构十分吸引我，我想看看是基于什么场景下的需求和业务设想，会形成这样的一个架构模式

随着训练营每日计划的推进，慢慢得从各个点，汇聚成了面，从各个面的角度结合资源上的平衡，逐渐形成一条条的线，觉得自己在架构层面又有了一些新的角度和思考的方式，对于 tidb 的各项原理和基础服务之间关系的理解也更加清晰

到了考试之日，说实话，第一次参考这种类型的考试，考试题目很多，时间也会比较紧，如果对于大纲或者知识点掌握的不够，很容易挂 …. 不过，我很幸运，第一次考试的就顺利的通过了，我只是觉得自己的一番努力没白费，还是很庆幸的；缘于这次考试，也认识了不少小伙伴，其实都怀着同样的一个目标，想要更了解 tidb

PCTA 之后，接着就是 PCTP 的学习和考试，对于当时的我，其实都很想放弃 PCTP 的考试，

1. 对于自己实力的了解，觉得肯定过不了

2. 精力有限，之前已经花了大把的时间来掌握 PCTA（其实觉得自己还没有那么熟练）

但是学习的机会不能浪费了，即使不参加考试，也得在拼一把，于是继续开始 PCTP 的学习，这个难度和 PCTA 是天差地别，每天学习也是觉得十分勉强，没有掌握的那么好，到了考试之日，果然挂掉了 …. 这个时候 4.0 发布了，又开放了新的课程，于是继续学习 ….

后续我在 asktug 特别活跃，坚信帮助他们的同时也是在帮助自己，“表妹”就出现了，问我愿意是否帮助她一起建设社区，答案是肯定的，同时还有更多的小伙伴也慢慢加入了这个团队；

在所有小伙伴一起的努力下，关注社区的人也就越来越多，问题也是五花八门，广度和深度都兼备，有时候觉得好多问题仍然很棘手，但是小伙伴多，不怕～～

目光

自认为是一个自律的人，对知识的渴望和追求从来都不曾停歇，当我遇到“表妹”，加入到社区团队后，才发现有比我更“卷”的小伙伴；

当然，我理解的这个“卷”描述的形式还不一样，形式无非两种：

• 主动推动

• 被动接受

主动努力的去推进一些事情， 总会比被别人来带动，被动接受的效果要好的多，但是想让自己能保持这个状态就很难，不过，这里有一群这样的小伙伴，然后有共同的目标和方向，就会有足够的力量支撑起来，状态就能够保持，继续前行！

• 我们都是追光者，追光而行不期而遇

• 偶遇一颗蓝色的小星球，感谢万有引力，将我拉向你

• 浩瀚宇宙中，我们虽然渺小，却绝不孤独

• in the vast universe , althought we are small , we are not alone