一、背景：国产化浪潮下的数据库选型
我是一名智慧教育软件开发商的运维工程师，负责公司产品的数据库运维工作。多年来，我们一直使用 MySQL 5.7 和 8.0 作为核心数据库，技术栈成熟，运维体系也相对完善。
2023 年起，一个明显的趋势开始出现——越来越多的客户在招标和沟通中问我们同一个问题："你们的软件支持国产数据库吗？" 国产化替代已经从政策层面的倡导，变成了客户实实在在的需求。到了 2024 年，公司正式将国产化数据库适配改造提上日程。
摆在面前的第一个问题是：选哪个国产数据库？
我们的软件是基于 MySQL 开发的，全量改造意味着巨大的人力成本和时间成本。因此，我们优先考虑与 MySQL 兼容性更强的数据库，力求将改造成本降到最低。经过多轮筛选和对比，最终选定了 TiDB——它在 MySQL 协议兼容性、分布式架构能力、社区活跃度和技术支持方面都表现突出，是当时最符合我们需求的选择。
二、转折：从"能跑就行"到必须深入
老实说，刚开始接触 TiDB 的时候，我的心态很"轻松"——把数据库装上、能跑起来就行了，反正是在开发测试环境，大不了重装，用备份还原数据就好。这种心态在纯开发测试阶段确实够用，但很快就被现实打破了。
2024 年下半年，我们一个省厅级客户要试用我司的软件，同时提出了一个硬性要求：必须使用国产化数据库。 这意味着 TiDB 不再仅仅服务于开发和测试环境，而是要真正承担起客户的生产业务。
这是一个本质性的转变。当数据库开始服务于真实客户，对稳定性和可用性的要求就完全不同了。我不能再用"重装大法"解决问题，必须对 TiDB 的原理、架构、故障排查有深入的理解，才能在出现问题时快速定位、高效处置。
带着这个目标，我开始在 TiDB 社区查阅文档，通过官方学习平台系统地学习 TiDB 的原理和核心架构，正式从"会用"迈向"懂原理"。
三、考证契机：从被动学习到主动认证
学习之初，我并没有考证的打算。我的出发点很纯粹：保证客户数据库稳定、可靠地运行。要实现这一点，就必须真正掌握数据库的原理和架构，才能在故障发生时快速分析原因、解决问题。
考证的机遇出现在 2025 年。当时 TiDB 推出了 TEM 敏捷试用活动，提交试用报告即可获得一次考试券。恰好在那个时间点，我刚学完 TiDB 数据库核心原理与架构课程，知识储备正处于最好的状态，于是借助这次机会一举拿下了 PCTA 认证。
到了 2026 年暑期，平凯又推出了新的免费考证活动，我借此机会继续冲刺，成功拿下了 PCTP 和 PCSD 两个证书。自此，TiDB 的三大认证全部收入囊中。
回头看，考证这件事与其说是目标，不如说是学习的副产品。真正驱动我深入学习的，是客户对生产稳定性的要求；而认证，则是对学习成果的一次系统性检验。
四、三大认证：考什么、怎么学
PCTA：TiDB 数据库核心原理与架构
PCTA 是 TiDB 认证体系的理论基石。核心学习材料是《101.1-TiDB 数据库核心原理与架构》课程，主要围绕 TiDB 的整体架构和四大核心组件展开：
- TiDB Server：无状态的 SQL 层服务，可根据需要部署一个或多个实例，支持在线动态扩缩容。建议至少部署两个节点以保障高可用。主要职责包括：处理客户端连接、SQL 语句的解析/编译/执行、关系数据与 KV 的转换、Online DDL 执行、垃圾回收等。
- TiKV：负责数据的持久化存储和读取，提供 MVCC 和分布式事务支持，基于 Raft 算法实现分布式事务一致性和多副本数据保存，还包含 Coprocessor 算子下推能力。
- PD（Placement Driver）：整个集群的"大脑"，负责元数据存储、全局时间戳 TSO 分配、TiKV 中 Region 的调度、全局事务 ID 分配、集群信息收集与调度等核心工作，保障集群稳定高效运行。
- TiFlash：负责列存数据，加速分析计算，通过异步复制方式将行存数据从 TiKV 同步过来，实现 HTAP（混合事务/分析处理）能力，避免了传统数仓场景中需要单独部署 ETL/ELT 的繁琐过程，在同一个数据库内自动实现 TP 和 AP 的计算分离。
此外，课程还深入讲解了 SQL 的执行流程、数据的写入与读取机制、HTAP 技术特性及其实现方式。
这部分课程中，我认为最难的是 TiKV 的数据落盘、数据读取、分布式事务、SQL 解析和算子下推的过程逻辑，以及各组件之间的工作关系。 我反复观看了几遍视频才理解了关键流程。
PCTP：TiDB 数据库管理
PCTP 与 PCTA 有明显区别：PCTA 偏重架构和原理，而 PCTP 更侧重于 实际操作和运维管理。核心学习材料是《303-TiDB 数据库管理》，覆盖的内容非常广泛：
- 集群部署：使用 TiUP 部署工具完成数据库集群的安装部署。
- 连接与管理：TiDB Server 的连接特性、对 MySQL 协议的支持、客户端连接方式和数据库监控功能。
- 参数配置：参数体系结构、参数作用域，以及通过配置文件和命令行两种方式修改数据库参数。
- 用户管理与安全：权限、用户、角色的管理，认证与权限授予、连接控制。
- 监控与诊断：借助 Prometheus、Grafana 和 Dashboard 等工具，监控关键指标和数据流转，快速了解集群状态、SQL 耗时，诊断集群问题和分析性能状况。
- 在线扩缩容：TiDB/TiKV/PD/TiFlash 节点的扩缩容操作与注意事项，尤其是缩容前保障数据安全的关键步骤，如调整数据表副本数、重构集群、修改时区等。
- 版本升级：停机升级和在线升级的流程、操作及常见问题处置。
- 备份与恢复：热备、冷备、温备的区别，逻辑备份、物理备份和增量备份的优缺点及选择建议；Dumpling 数据导出工具、TiDB Lightning 数据导入工具、BR 备份恢复工具的原理、使用场景和使用方法；sync-diff-inspector 数据校验工具的功能与使用。
- 数据同步：TiDB Data Migration（DM）和 TiCDC 两个同步工具的原理架构、使用场景和使用方法。
- 高可用架构：系统评判指标、不可用原因分析、高可用解决方案；同城三中心、同城两中心、两地三中心、异步复制等架构方案与高可用架构升级。
- TEM 企业管理平台：集群概览、Top5 SQL、性能趋势、资源状态、集群创建与纳管、拓扑管理、信息监控、慢查询与 Top SQL 诊断、SQL 模板与执行计划、数据闪回/还原/备份、集群与主机巡检、TEM 架构与部署。
- TMS 迁移工具：核心功能、安装部署和使用。
PCSD：TiDB 应用开发
PCSD 主要面向开发人员，侧重于在应用层正确、高效地使用 TiDB：
- 数据查询与处理：数据类型、函数、表达式、表连接和子查询。
- TiDB 特色功能：AUTO_RANDOM、AUTO_INCREMENT 的注意事项、全局临时表、TiFlash 启用 HTAP、放置策略等。
- Java 连接器：通过 JDBC 连接 TiDB，以编程方式执行 SQL 查询与数据修改。
- 开发最佳实践：客户端连接配置、异常处理、事务使用建议、字段属性与表选项设置、SQL 写作规范、批处理利用等。
五、学习方法论：理论与实验，缺一不可
PCTA：理论靠"画"
PCTA 主要偏向理论，需要真正理解课程中的每一个知识点，尤其是 TiKV 中数据落盘、数据读取、分布式事务、SQL 解析和算子下推的过程逻辑，以及各组件之间的工作关系。
我的学习方法是这样的：
- 反复观看视频，第一遍建立整体印象，第二遍关注细节。
- 脱离视频，凭印象完整画一遍流程逻辑——从 SQL 请求到达到最终数据落盘，每一个环节都画出来。
- 将自己画的流程与老师讲解的对比，找出遗漏或理解错误的地方。
- 回到视频重新观看，修正认知，直到整个过程可以独立、完整地画出来。
这个"画图法"非常有效。它强迫你主动回忆和组织知识，而不是被动地接收信息。当你能不看任何资料把整个数据流转过程画出来的时候，说明你是真的理解了。
PCTP：实践靠"练"
PCTP 偏重实践，必须多做实验。我的学习路径是：
- 跟做阶段：一边看老师讲解视频，一边跟着操作，遇到问题翻阅官方文档。TiDB 的文档非常全面，几乎可以覆盖实验中遇到的所有问题。
- 记笔记阶段：记录关键步骤，脱离视频，根据笔记独立操作。
- 独立完成阶段：不用笔记，独立完成整个操作流程。
- 对照理解阶段：结合视频和理论部分，对照理解每个知识点背后的原理。
- 探索阶段（进阶）：在能独立完成标准实验后，尝试一些非推荐场景或不按标准流程操作，记录错误现象和排查过程——这能为后续实际运维中遇到的问题提前积累经验。
这个"探索阶段"特别有价值。在安全的环境中主动制造问题、分析问题、解决问题，远比在客户生产环境中被动救火要好得多。
六、收获与思考
收获一：认证倒逼深度学习
通过认证考试，迫使我更加深入地学习数据库。说实话，如果没有考证这个目标，学习视频很可能就是走马观花地看一遍，不会有那么深入的理解。认证给了学习一个明确的终点和验收标准，让"差不多行了"变成了"必须搞懂"。
这个体会让我意识到：有时候，给自己设定一个外部验证的截止日期，比纯粹的内部动机更有效。
收获二：从"分库分表"到"分布式原生"
在学习 TiDB 之前，我对分布式数据库的理解很有限。以前认为，应对高并发和大数据量，无非就是 MySQL 的分库分表、分区存储那一套——应用层做路由、做合并，运维层做各种中间件适配，复杂且脆弱。
现在我知道了，分布式数据库可以从架构层面原生地解决横向扩容的问题。TiKV 以 Region 为单位自动分裂和迁移，PD 负责全局调度，扩容时只需要加节点、数据自动均衡，缩容时只需安全地下线节点。这种"对应用透明"的扩展能力，是传统分库分表方案无法比拟的。
这种认知的转变，不只关乎 TiDB 本身，更关乎我对"数据库"这件事的整体理解——从"一个存储引擎 + 各种补丁"到"一个原生分布式的数据平台"。
收获三：原理是运维的底气
回头看我最初"能跑就行"的心态，本质上是缺乏原理支撑时的无奈之举。当数据库出了问题却不知道该从哪里查起，最简单的办法就是重启和重装。但这种方式在客户生产环境中是不可接受的。
深入学习 TiDB 的架构和原理之后，面对故障时的心态完全不同了：知道数据在 TiKV 中以什么格式存储、知道 Raft 协议如何保证一致性、知道 PD 如何调度 Region、知道 SQL 语句经过了哪些解析和优化步骤……这些知识构成了故障排查的"地图"，让你知道问题可能出在哪里、该用什么工具去验证、该怎么修。
原理不是理论，是运维工程师在凌晨三点处理故障时的底气。
写在最后
从 2024 年因为客户需求开始接触 TiDB，到 2026 年拿下三大认证，这段经历让我对"学习"这件事有了新的理解：
最好的学习，不是为了考证，而是为了解决问题；但考证，可以让解决问题的学习更加系统和深入。
TiDB 三大认证的考取，对我来说不是终点，而是一个新的起点。PCTA 让我懂了原理，PCTP 让我会了运维，PCSD 让我理解了开发视角。三者结合，才是一个完整的数据库工程师应该具备的能力图谱。
国产化数据库的浪潮还在继续，客户的信任建立在我们的专业能力之上。而专业能力，正是在这一次次"必须搞懂"的深入学习和"亲手做过"的实践积累中，一点一点建立起来的。