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