前言
作为一名在互联网电商行业摸爬滚打五年的后端开发，我经历过无数次大促前的“祷告”，也习惯了半夜被报警短信叫醒——原因永远是那几个：MySQL 主库 CPU 飙红、慢查询堆积、分库分表后的 Join 失效。直到今年年初，团队启动核心交易系统的重构项目，我迎来了职业生涯中一次重要的技术转型：全面拥抱 TiDB。
这篇文章，我将复盘从接触 TiDB、参与选型、系统学习到最终拿下 PCTA/PCTP 认证的完整历程，希望给同样在数据库瓶颈中挣扎的你一点参考。
一、为什么选择 TiDB？
1.1 旧系统的痛点：分库分表的“死胡同”
我们的订单系统原本基于 MySQL 构建，随着业务量激增，数据量很快突破单机瓶颈。最初采用的方案是 MyCAT + MySQL 分库分表。
听起来很美，但现实很骨感：
- 业务逻辑复杂化：为了规避跨分片 Join，我们不得不把很多关联查询拆成多次 RPC 调用，代码臃肿不堪。
- 扩容成本高：每次大促前都要提前几个月评估容量，手动迁移数据，运维压力巨大。
- 实时分析难：订单数据需要同步到 ES 或 Hive 做分析，链路长，延迟高，运营同学经常抱怨数据不准。
1.2 选型调研：HTAP 进入视野
在重构方案讨论会上，架构师提出了一个灵魂拷问：“有没有一种数据库，既能像 MySQL 一样做 OLTP，又能像 ClickHouse 一样做 OLAP？”
于是，我们将目光投向了 HTAP（混合事务/分析处理） 数据库。经过横向对比（CockroachDB, YugabyteDB, TiDB），最终选择了 TiDB，理由如下：
对比维度 |
MySQL (分库分表) |
TiDB |
|---|---|---|
扩展性 |
手动扩容，数据迁移复杂 |
在线水平扩缩容，对业务透明 |
SQL 兼容性 |
标准 MySQL，但受限于分片规则 |
100% MySQL 协议兼容，支持复杂 Join |
一致性 |
最终一致（跨库） |
强一致性（基于 Raft） |
分析能力 |
弱，需 ETL 同步 |
内置列存引擎 TiFlash，实时分析 |
运维成本 |
高，依赖 DBA 经验 |
云原生架构，自动化运维程度高 |
最关键的一点是：迁移成本极低。TiDB 完全兼容 MySQL 协议，我们的应用代码几乎无需修改即可平滑迁移，这极大地降低了重构风险。
二、学习 TiDB 的意义
起初，我对学习一款新数据库是抗拒的。市面上数据库那么多，为什么要花大力气学 TiDB？但随着研究的深入，我发现这不仅是学一个工具，更是一次技术视野的升级。
2.1 跳出“CRUD”的舒适区
作为业务开发，平时大多关注业务逻辑。但掌握 TiDB 让我开始深入理解 分布式一致性算法（Raft）、MVCC（多版本并发控制）、分布式事务（Percolator 模型）。这些底层原理在分布式系统中是通用的，学会了 TiDB，再看其他分布式中间件都会豁然开朗。
2.2 解决业务痛点的硬实力
在电商场景中，“库存扣减”和“订单创建”往往存在延迟。TiDB 的 HTAP 特性让我们可以在同一个数据库中完成 T+0 的实时数据分析，比如实时统计爆款商品销量，直接指导供应链补货，这在以前是无法想象的。
2.3 职业竞争力的护城河
云原生和分布式已经成为标配。拥有 TiDB 的实战经验和 PCTP（TiDB 认证专家）证书，无疑是在简历上增加了浓墨重彩的一笔，证明了自己具备解决海量数据场景下复杂问题的能力。
三、学习 TiDB 的体验和收获
3.1 备考之路：从 PCTA 到 PCTP
我的学习路径非常清晰：先考 PCTA（助理工程师），再冲 PCTP（专家）。
- PCTA 阶段：主要考察基础概念、部署架构和 SQL 优化。我利用每天通勤时间在 平凯星辰 官方文档 上啃完了《TiDB 简介》和《SQL 基本操作》。TiDB Cloud 提供了免费的 Dev Tier，我直接在云端建集群练手，熟悉 Dashboard。
- PCTP 阶段：难度陡增，重点在于故障排查、性能调优和内核原理。这里我踩了一个大坑：只看书不实操。第一次模拟考关于 PD 调度策略的题目错了一半。后来我搭建了本地的 3 节点集群，故意 kill 掉节点模拟宕机，观察 Region Leader 的迁移过程，才真正理解了
leader-weight和region-weight的作用。
3.2 实战干货与踩坑记录
在将订单服务迁移至 TiDB 的过程中，我总结了几点血泪教训：
-
热点问题（Hotspot）
- 现象：刚上线时，发现写入集中在某个 TiKV 节点。
- 原因：订单表的主键是自增 ID，导致写入总是在最后一个 Region。
- 解决：启用
SHARD_ROW_ID_BITS，或者使用随机主键（如 UUID）。在生产环境中，我们采用了雪花算法生成的主键，彻底解决了写入热点。
-
乐观锁与悲观锁
- 坑点：TiDB 3.x 默认是乐观锁，我们在做库存扣减时出现了少量超卖。
- 解决：升级到 TiDB 4.0+ 并开启悲观锁模式（
tidb_txn_mode = 'pessimistic'），或者显式使用BEGIN PESSIMISTIC。现在的新版本默认就是悲观锁，但在老版本迁移时要特别注意这一点。
-
执行计划绑定（SPM）
- 技巧：线上某条慢 SQL，在测试环境跑得飞快。排查后发现是统计信息不准确导致优化器选错了索引。
- 收获：学会了使用
CREATE BINDING强制绑定执行计划，并利用ANALYZE TABLE定期收集统计信息，确保优化器“聪明”决策。
3.3 学习资源推荐
- 必读：TiDB 官方文档（中文质量极高）
- 必练：TIUP 工具
四、所在行业 TiDB 的适用场景
结合电商行业的特性，我认为 TiDB 在以下几个场景中具有统治级优势：
4.1 海量订单存储与查询
电商订单数据是典型的“写多读少”且数据量巨大。TiDB 的弹性扩容能力允许我们轻松应对亿级订单存储，且历史订单查询不再需要复杂的归档逻辑，冷热数据统一存储，查询体验极佳。
4.2 实时大数据分析（BI 报表）
这是 TiDB 最惊艳我的地方。通过部署 TiFlash 列式存储节点，我们可以在不影响 OLTP 业务的前提下，直接对订单库进行多维度分析。例如，双十一当天实时大屏，以前是靠 Flink + OLAP 数据库异步计算，现在直接一条 SQL 搞定，延迟从分钟级降到了秒级。
4.3 替换复杂的分库分表中间件
对于那些已经深陷 Sharding-JDBC 或 MyCAT 泥潭的老系统，TiDB 是最佳的“逃生舱”。它屏蔽了底层的数据分布细节，让开发人员回归业务逻辑本身，大大提升了研发效率。
4.4 多数据中心容灾
电商业务对高可用要求极高。TiDB 的原生多中心部署方案（如两地三中心），可以保证在单机房甚至单城市故障时，数据库服务自动切换，RPO=0，RTO<30s。