做 DBA 这些年，Oracle RAC、ASM、ADG 、MySQL 主从摸得差不多了，KingbaseES、GBase、OB 这些国产库也都接触过。为什么还去考 TiDB的PCTA、PCTP、PCSD 三张证？
说实话，最开始不完全是"想学"，更多是"有点慌"。
这两年 AI 写 SQL、排故障的能力肉眼可见地在涨，很多以前靠经验积累的判断，现在借助工具新人也能摸到门道。DBA 这活儿会不会被稀释，我心里真没底。工作又不好找，简历投出去经常没下文。这种时候能证明自己"还在往前走"的东西不多，考个证至少是个实实在在的东西，不一定马上换来 offer，但面试的时候心里能多点底气。
一、为什么选 TiDB
单机 MySQL 分库分表这条路，做过的人都知道有多折腾——跨库事务、跨库 join、分片键设计，中间件能缓解但本质是打补丁，运维复杂度只增不减。传统主从切换在网络分区、脑裂场景下也总要在一致性和可用性之间做取舍，这块我在 Oracle RAC 上吃过太多类似的苦。
再加上这几年信创大背景下，政企客户选型清单上"自主可控"的权重越来越重，TiDB 虽然架构上借鉴了 Google Spanner/F1 的思路，但作为社区活跃、生态相对成熟的分布式数据库，落地案例多、接受度也高。还有一点吸引我的是 HTAP：业务库既要扛高频写入，又要支撑报表和审计类查询，传统做法是搭一套 OLTP + ETL + OLAP 的链路，又长又难维护。TiDB 靠 TiFlash 的列存副本能把这条链路省掉一大截。
说到底，TiDB 是在容量、高可用、国产化、HTAP 这几个我自己技术栈里比较薄弱的地方，正好能补上。
二、学它图什么
一是补认知。长期泡在 Oracle 和 MySQL 的"单机+主从"思路里，人容易被框住。PD 怎么调度、Region 怎么分裂合并、Raft 怎么保证一致性，这些概念逼着我重新理解分布式数据库到底是怎么回事，不是简单一个"能自动分片的 MySQL"。
二是给自己留条后路。前面说的焦虑不是瞎担心的——基础调优、日常巡检这类活儿被工具分担之后，DBA 真正值钱的地方会越来越集中在架构设计和复杂故障定位上，分布式数据库这几年招聘市场里含金量确实在涨，多学一门总不亏。
三是证书本身有点"信号"作用。PCTA、PCTP、PCSD 三级基本覆盖了从基础运维到架构设计的完整链条，招聘方看着是个相对标准的能力证明，对我自己来说，备考也逼着我把零散知识点系统地过一遍，而不是用到啥查啥。
三、备考的体验
PCTA 主要打基础，架构、部署、DDL/DML 差异、和 MySQL 协议兼容的边界在哪，这部分不算难，真正花时间的是理解 PD 怎么做调度决策。
PCTP 难度上了一个台阶，开始涉及执行计划、索引选择、乐观/悲观事务、故障排查思路。印象最深的一次坑，是本地模拟热点写入，一开始没搞懂 Region 分裂的触发机制，某个 Region 的写入压力一直压不下去，后来才明白得从业务主键设计上规避（比如别用自增主键，改用 AUTO_RANDOM 或者业务分片键）。这种理论看着简单、实操才知道坑在哪的感觉，比刷题印象深多了。
PCSD 基本是架构师视角了：容量规划、多副本策略、跨机房容灾、备份恢复、性能诊断方法论。考到这一步，明显感觉自己看选型这件事的角度变了，以前想的是"这个库能不能用"，现在会本能地想"这套架构在什么数据量、什么并发、什么容灾要求下会先撑不住"。
整体收获是，技术上补了分布式这一块，心态上也算给自己找了个能量化的"我在往前走"的证据。当然证书不是万能药，解决不了大环境的问题，但至少面试的时候能多聊几个有细节的话题，不至于干巴巴一句"我熟悉分布式数据库"。
四、我这个行业里 TiDB 适合用在哪
结合我接触的政企、传统企业信息化、部分交易类系统的经验，比较适配的场景大概是：订单支付流水这类增长快的交易表，用 TiDB 自动分片能省掉一堆中间件的运维成本；有信创要求的项目，TiDB 生态相对更成熟，落地风险可控一些；既要实时读写又要跑报表分析的场景，用 TiFlash 能省掉一整套 ETL 链路；还有不想自己维护复杂主从切换逻辑、又对高可用要求高的场景，TiDB 基于 Raft 的多副本机制天然占优势。
但也不是万能解——强一致性要求极高、单机性能本来就够用、团队又没有分布式运维经验的场景，硬上反而会增加复杂度。选型这事，永远是业务场景优先，技术追新在后。
写在最后
回头看这段从了解 TiDB 到考完三张证的过程，与其说是技术升级，不如说是在不确定的环境里给自己找点确定性。AI 会不会重塑这个行业，工作会不会更难找，我给不出答案，但至少多掌握一门扎实的技术、多一张能经得起追问的证书，是现在能做、也值得做的事。