学习 TiDB 的 30 天：一个新人的踩坑日记与思维转变

前言

这篇文章不是架构科普，也不是认证攻略，而是一份真实的"学习踩坑日记"。

作为一个之前只接触过 MySQL 的后端开发，我在过去 30 天里集中学习了 TiDB。过程中踩了不少坑，走了一些弯路，也经历了几次"原来如此"的思维转变。把这些经验写下来，希望能帮同样在学习 TiDB 的新人少走弯路。

一、最大的坑：用 MySQL 的思维去理解 TiDB

学 TiDB 的第一周，我犯了一个几乎所有 MySQL 背景的开发者都会犯的错误——用 MySQL 的思维去理解 TiDB。

表面上看，TiDB 兼容 MySQL 协议，SQL 语法几乎一样，连接方式也一样，甚至连 Navicat 都能直接连。这会给你一种"不就是个 MySQL 吗"的错觉。但当你深入使用后就会发现，同样一条 SQL，背后的执行逻辑可能完全不同。

踩坑一：自增主键的"坑"

在 MySQL 中，AUTO_INCREMENT 是最常用的主键设计。我习惯性地在 TiDB 上也用了 AUTO_INCREMENT，结果在批量插入数据时遇到了写入热点问题——所有写入都集中在一个 TiKV 节点上，性能远不如预期。

原因：MySQL 的 AUTO_INCREMENT 生成的是连续递增的 ID，在单机环境下没有问题。但在 TiDB 的分布式架构中，连续递增的 Key 会导致所有新写入都落在同一个 Region（数据分片）上，形成"热点"。

正确做法：TiDB 提供了 AUTO_RANDOM 来替代 AUTO_INCREMENT。它会生成随机分布的 ID，让写入均匀分散到不同的 Region 和 TiKV 节点上。

这个坑让我第一次深刻意识到：兼容 MySQL 不等于就是 MySQL。SQL 语法兼容只是"面子"，底层的分布式存储机制才是"里子"，你需要理解它才能用好它。

踩坑二：以为"加索引就能提速"

在 MySQL 中，查询慢了加个索引基本就能解决。我把这个习惯带到了 TiDB，发现有时候加了索引，查询反而更慢了。

原因：TiDB 的优化器（CBO，基于代价的优化器）在生成执行计划时，会根据统计信息评估不同方案的代价。如果统计信息不准确或者过期，优化器可能选择了一个并不最优的执行计划。此外，TiDB 的索引和 MySQL 的 B+Tree 索引在底层实现上也有差异——TiKV 的索引是独立的 Key-Value 数据，查询索引后还需要一次额外的回表操作。

正确做法：

• 使用 EXPLAIN ANALYZE 而不仅仅是 EXPLAIN 来查看实际执行统计信息

• 定期执行 ANALYZE TABLE 更新统计信息

• 善用 TiDB Dashboard 的慢查询分析功能，它能直观地展示执行计划和耗时分布

踩坑三：事务行为差异

在 MySQL（InnoDB）中，默认隔离级别是 RR（可重复读），事务的行为比较直观。TiDB 也默认使用 RR 隔离级别，但底层实现机制完全不同——TiDB 使用的是基于 TSO（全局时间戳）的 Snapshot Isolation，而非 MySQL 的基于锁和 undo log 的实现。

这意味着一些在 MySQL 上"理所当然"的行为，在 TiDB 上可能有细微差异。例如，TiDB 不支持 SELECT ... FOR UPDATE 的 GAP Lock 语义，也不支持 LOCK TABLES 语法。如果你的业务逻辑依赖了这些特性，迁移时需要特别注意。

教训：不要假设"MySQL 上能跑的 SQL，在 TiDB 上行为完全一样"。遇到行为差异时，查阅官方文档的与 MySQL 兼容性章节，这是最权威的参考。

二、思维转变：从"单机思维"到"分布式思维"

踩坑的过程也是思维转变的过程。学习 TiDB 的第二周，我逐渐意识到，学 TiDB 最大的挑战不是记住几个组件的名字，而是完成从"单机思维"到"分布式思维"的转变。

转变一：从"加配置"到"加节点"

MySQL 扛不住了怎么办？加内存、换 SSD、升级 CPU。再不行？读写分离、分库分表。总之，是在一台机器上做文章，或者用中间件把多台机器"粘"起来。

TiDB 的思路完全不同——扩容就是加节点。计算层（TiDB Server）不够了？加节点。存储层（TiKV）不够了？加节点。数据怎么分配？不用管，PD（Placement Driver）会自动把数据 Region 调度到新节点上。

这种"弹性"在 MySQL 的世界里是很难想象的。在 MySQL 里加一台从库，你得配置主从复制、设置读写分离规则、处理主从延迟……而在 TiDB 里，加一个 TiKV 节点，PD 会自动感知并开始数据再均衡，整个过程对业务完全透明。

思维转变的核心：从"在单机上做优化"转变为"通过水平扩展来提升能力"。这不是技术细节的差异，而是架构哲学的差异。

转变二：从"主从复制"到"Raft 多副本"

MySQL 的高可用方案通常是主从复制：一个主库写，多个从库读，主库挂了选一个从库顶上。这套方案能用，但有很多痛点——主从延迟、数据一致性不保证、切换需要外部工具（MHA、Orchestrator）、切换过程可能丢数据……

TiDB 的方案是在存储层内置 Raft 协议：每个 Region 默认 3 个副本，分布在不同的 TiKV 节点上，通过 Raft 多数派写入保证一致性。Leader 挂了？Raft 自动选新 Leader。整个故障检测和切换过程在秒级完成，不需要任何外部工具。

理解这个转变很重要，因为它改变了你对"高可用"的认知——高可用不再是需要外部组件来"补"的能力，而是数据库内核原生就具备的能力。

转变三：从"OLTP + OLAP 两套系统"到"HTAP 一套搞定"

以前做数据分析，标准架构是 MySQL（OLTP）+ ETL + ClickHouse/Hadoop（OLAP），两套系统、两份数据、几个小时的同步延迟。

TiDB 的 HTAP 架构让我看到了另一种可能：TiKV（行存）负责事务处理，TiFlash（列存）负责分析查询，两者通过 Raft Learner 实时同步。优化器自动决定走行存还是列存，用户不需要关心。

当然，HTAP 不是万能的。我在学习中也认识到，TiFlash 会额外占用存储空间，实时同步也会带来写入开销。资源有限的场景下是否引入 TiFlash，需要根据实际负载来评估。但至少在架构层面，"一套系统搞定 OLTP + OLAP"的思路确实大大简化了系统复杂度。

三、学习资源评估：哪些值得花时间，哪些可以跳过

30 天的学习过程中，我接触了各种 TiDB 学习资源。这里分享我的个人评估，供大家参考。

第一梯队：必看资源

第二梯队：推荐资源

第三梯队：按需使用

我的血泪教训：学习第一周我花了很多时间看各种第三方博客和视频，结果发现有些内容已经过时（讲的是 v3 或 v4 版本），有些说法和官方文档不一致。后来我调整策略——以官方文档为主，第三方资料仅作补充参考，学习效率立刻提升了。

四、我的 30 天学习计划

这里分享我的实际学习节奏，不一定适合所有人，但可以作为一个参考框架。

第 1-7 天：建立认知 + 动手跑起来

• 目标：理解 TiDB 是什么，能跑起来一个本地集群

• 行动：

  • 通读官方文档"TiDB 简介"和"核心概念"章节
  • 用 tiup playground 启动本地集群
  • 用 MySQL 客户端连接，跑几条 SQL 感受一下
  • 打开 TiDB Dashboard，看看集群状态

第 8-14 天：深入架构 + 理解原理

• 目标：理解 TiDB 的三层架构和核心机制

• 行动：

  • 学习官方 101 课程（架构原理部分）
  • 重点理解：TiDB Server / TiKV / PD 的职责
  • 学习 Raft 协议在 TiKV 中的应用
  • 理解 Region、MVCC、TSO 的概念
  • 在 Dashboard 上观察 Region 分布和调度

第 15-21 天：实操体验 + 踩坑学习

• 目标：通过实际操作加深理解

• 行动：

  • 导入一批测试数据（可以用 Dumpling + Lightning）
  • 跑业务 SQL，验证兼容性，记录差异
  • 故意制造热点写入（用 AUTO_INCREMENT），观察 Dashboard
  • 用 EXPLAIN ANALYZE 分析慢查询
  • 模拟 TiKV 节点故障，观察自动恢复

第 22-28 天：工具生态 + 进阶主题

• 目标：了解周边工具和进阶特性

• 行动：

  • 学习 BR（备份恢复）、DM（数据迁移）、TiCDC（数据同步）
  • 了解 TiFlash 的 HTAP 能力
  • 学习基本的 SQL 调优方法
  • 尝试使用 Grafana 监控面板

第 29-30 天：总结复盘 + 社区参与

• 目标：梳理知识体系，参与社区

• 行动：

  • 整理学习笔记，画一张 TiDB 架构思维导图
  • 在 AskTUG 论坛上回答几个新人的问题（教是最好的学）
  • 浏览社区博客，看看别人的实战经验
  • 评估自己是否准备好参加 PCTA 认证

五、给新人的几条实用建议

经过 30 天的学习，以下是我最想跟新人分享的几条建议：

1. 先动手，后看理论

不要一上来就啃文档看视频。先花 10 分钟用 tiup playground 跑起来一个集群，连上去跑几条 SQL，打开 Dashboard 看看。有了直观感受之后，再去看架构原理，理解会深刻得多。

2. 带着 MySQL 的经验来，但别被它困住

MySQL 的经验是你的优势，但也会是你的盲区。TiDB 兼容 MySQL 协议这件事太有迷惑性了——它会让你误以为"不用学也能用"。事实上，正因为语法兼容，行为上的细微差异反而更容易让人掉以轻心。保持警觉，遇到"和 MySQL 不一样"的地方就记下来。

3. Dashboard 是最好的老师

TiDB Dashboard 是理解分布式数据库运作的绝佳窗口。Region 分布、热点调度、慢查询分析、Raft 状态……这些在 MySQL 里看不到的东西，在 Dashboard 上都能直观地观察到。养成"遇到问题先看 Dashboard"的习惯。

4. 关注版本号

TiDB 迭代很快，不同版本之间特性差异可能很大。看文档、博客、视频时，一定要确认它讲的是哪个版本。我踩过的坑里，有一半是因为参考了旧版本的资料。建议始终以最新稳定版的官方文档为准。

5. 教是最好的学

当你学了一些东西后，试着在社区论坛上回答其他新人的问题。你会发现，能看懂和能讲清楚是两个完全不同的层次。每次帮别人解答问题，自己的理解也会加深一层。

6. 接受"不可能一次学完"这个事实

TiDB 的知识面很广——架构、存储、事务、优化、工具、运维……不要试图一次性全部掌握。先建立整体框架，然后在实践中逐个深入。学习是螺旋上升的，不是一条直线。

写在最后

30 天的 TiDB 学习之旅，我最大的收获不是记住了多少知识点，而是完成了一次思维方式的转变——从单机数据库的思维惯性中跳出来，开始用分布式的视角去思考数据存储和处理的问题。

这个转变不轻松，中间踩了不少坑，走过不少弯路。但正是这些坑和弯路，让我的理解更加扎实。如果你也在学习 TiDB，希望这份踩坑日记能帮你少走一些弯路。

记住：TiDB 兼容 MySQL，但不等于 MySQL。理解差异，才是学习的真正开始。