写在前面
过去一年多，我先后拿下了 MySQL OCP、TiDB PCTA（TiDB 认证专员）和 TiDB PCTP（TiDB 认证专家）三张证书。从单机关系型数据库到分布式 NewSQL，这条认证路走下来，收获的远不止三张纸。
今天把这段经历完整复盘一遍，既是给自己留个记录，也希望能给正在备考或犹豫要不要考的朋友一点参考。
一、为什么是这三张证
先说背景。我从事数据库运维工作，日常打交道最多的就是 MySQL。随着业务量增长，单库瓶颈越来越明显，分库分表带来的运维复杂度也让人头疼。团队开始调研 TiDB，我自然就成了第一批吃螃蟹的人。
考证的动机很实际：
MySQL OCP：用了这么多年 MySQL，一直是"野路子"，想系统补一遍底层原理，顺便拿个官方认证背书。
TiDB PCTA：公司要上 TiDB，先考个入门级认证，逼自己快速建立知识体系。
TiDB PCTP：入门之后发现水很深，DBA 级别的能力必须跟上，干脆一鼓作气冲专家级。
三张证，一条清晰的技术成长线：从熟悉的 MySQL 出发，走向分布式数据库的深水区。
二、MySQL OCP：重新认识"最熟悉的陌生人"
备考过程
MySQL OCP 考试覆盖的面很广：架构原理、安装配置、备份恢复、复制高可用、性能优化、安全管理……每一块都是日常工作在碰，但真到系统学习的时候才发现，很多东西我只是"会用"，并不"懂"。
举个例子，InnoDB 的 MVCC 机制，以前只知道"快照读不加锁"，备考时才把 Read View、undo log、事务隔离级别之间的关系彻底串起来。再比如半同步复制，以前配置完就不管了，现在才理解 rpl_semi_sync_master_timeout 背后的权衡逻辑。
备考用了大概两个月，每天下班后刷两小时。官方教材 + 实验环境反复验证，很多知识点动手做一遍比看十遍书都管用。
最大的收获
不是证书本身，而是建立了一套排查问题的系统思维。以前遇到慢查询，先看执行计划，不行就加索引；现在会从 SQL 写法、索引设计、统计信息、执行计划、锁等待、IO 压力多个维度去分析，思路清晰了很多。
三、TiDB PCTA：推开分布式数据库的门
从零开始的认知冲击
考完 MySQL OCP 没多久，团队正式启动 TiDB 试点。我报名了 PCTA 认证，以此为抓手系统学习。
TiDB 给我的第一个冲击是架构思维的转变。MySQL 是单机思维，所有问题都在一个实例里解决；TiDB 是分布式思维，计算层（TiDB）、存储层（TiKV）、调度层（PD）各司其职，一个 SQL 要经过协议解析、执行计划生成、Region 路由、分布式执行、结果聚合等多个环节。
PCTA 的考点相对基础：架构组件、部署运维、基本 SQL 操作、数据迁移、简单故障排查。但对习惯了 MySQL 的人来说，每一个概念都需要重新理解——比如 Region 是什么、Raft 协议怎么保证一致性、PD 怎么做调度、TiFlash 列存为什么能加速分析。
踩过的坑
备考期间在测试环境部署了一套三节点 TiDB 集群，第一次扩容 TiKV 节点时，因为没注意磁盘空间，导致 Region 调度过程中出现磁盘满告警，整个集群写入受阻。后来翻文档才知道，扩容前要评估空间、调整调度参数、观察调度进度。这个小事故让我对"分布式系统没有小事"这句话有了切身体会。
四、TiDB PCTP：走进深水区
难度的跃升
如果说 PCTA 是"会用 TiDB"，PCTP 就是"管好 TiDB"。考试难度明显上了一个台阶，重点考察：
分布式执行计划解读与 SQL 调优；TiKV 底层原理（RocksDB、Raft、MVCC、GC）；集群性能调优（参数调优、读写热点处理、Region 调度）；高可用与故障恢复（节点宕机、网络分区、数据恢复）；数据迁移与同步（DM、TiCDC、BR 备份恢复）；云上部署与资源规划。
备考用了将近三个月。这段时间几乎把官方文档翻了个遍，很多章节读了不止一遍。TiDB 的文档质量很高，但内容也多，需要反复消化。
最有价值的部分
SQL 调优是 PCTP 的核心，也是日常工作中最实用的技能。TiDB 的执行计划和 MySQL 有相似之处，但分布式执行计划多了很多算子：IndexLookUp、IndexHashJoin、TableReader、TableScan……理解每个算子的行为，才能判断执行计划是否合理。
印象最深的一次调优：一条关联查询在 MySQL 上毫秒级返回，迁到 TiDB 后要十几秒。看执行计划发现走了 HashJoin 且大表做了全表扫，通过添加联合索引、改写 SQL、使用 SPLIT REGION 打散热点，最终优化到百毫秒以内。这个过程让我真正理解了"分布式数据库的调优思路和单机数据库完全不同"。
五、三张证考完，我的几点思考
1. 认证不是终点，是系统化学习的起点
说实话，考证之前我也觉得"证书没用，能力才重要"。但走完这一圈才发现，认证最大的价值是逼你建立完整的知识体系。日常工作是点状的，遇到什么学什么；认证备考是面状的，它会强迫你把每个角落都走一遍，补上那些"以为自己懂其实不懂"的盲区。
证书本身不能证明你多厉害，但备考过程中建立的知识框架，会在未来某个问题排查的瞬间，突然帮到你。
2. MySQL 和 TiDB 不是替代关系，而是互补
很多人问我："TiDB 是不是要取代 MySQL？"我的答案是否定的。
TiDB 擅长的是海量数据下的高并发写入和实时分析，它的分布式架构天然解决了单机容量和性能瓶颈。但 TiDB 的运维复杂度、资源消耗、延迟表现，在中小规模场景下并不比 MySQL 有优势。
实际生产中更合理的架构是：核心交易用 MySQL，海量数据和分析场景用 TiDB，通过 TiCDC 或 DM 做数据同步。理解了两者的优劣，才能在架构选型时做出正确判断。
3. 分布式数据库对 DBA 提出了新要求
从 MySQL 到 TiDB，DBA 的能力模型在变化：
以前只需要懂数据库本身，现在还要懂分布式系统、网络、存储、容器编排；以前的问题排查是"单实例纵向深入"，现在是"多节点横向关联"；以前的高可用靠主从复制，现在靠 Raft 共识和自动故障转移；以前的性能瓶颈在单机，现在的瓶颈可能在网络、在调度、在热点 Region。
未来的 DBA，一定是兼具传统数据库功底和分布式系统视野的复合型人才。这也是我选择这条认证路线的根本原因。
4. 动手实验比刷题重要一万倍
三张证考下来，我最大的体会是：一定要搭实验环境，一定要动手踩坑。
看文档觉得懂了，和实际操作中遇到问题、排查问题、解决问题，完全是两回事。备考期间我搭了两套 TiDB 集群（一套物理机、一套 K8s），做了无数次备份恢复、扩容缩容、故障注入、SQL 调优实验。这些实验中踩过的坑，比任何题库都记得牢。
六、给后来者的建议
如果你也在考虑走这条路，几点建议：
1. 先夯实 MySQL 基础。理解了单机数据库的原理，再学分布式数据库会事半功倍。
2. 不要为了考证而考证。把认证当成学习的脚手架，重点是过程中的知识积累，不是那张证书。
3. 动手！动手！动手！重要的事情说三遍。没有实验环境的备考，都是纸上谈兵。
4. 关注社区。TiDB 的社区非常活跃，官方文档、AskTUG 论坛、技术公众号都是很好的学习资源。
5. 保持耐心。分布式数据库的学习曲线比 MySQL 陡很多，初期会有很多概念听不懂，坚持下去，某一天会突然融会贯通。
写在最后
从 MySQL OCP 到 TiDB PCTA，再到 TiDB PCTP，这一年多的时间，是我技术成长最快的一段日子。三张证书摆在那里，提醒我曾经系统地学过、认真地做过。
但我也清楚，认证只是入门。真正的能力，来自生产环境中一个个被解决的问题，来自一次次凌晨的故障排查，来自对技术本质持续不断的追问。
数据库的世界很大，从单机到分布式，从关系型到多模，从人工运维到智能运维，变化永远在发生。保持学习，保持好奇，保持动手——这大概是我这一年多最大的收获。
与各位同行共勉。
如果你也在备考数据库认证，或者在 TiDB 落地过程中遇到问题，欢迎留言交流。