前言
2022 年 3 月，我第一次系统学习 TiDB，并通过了 PCTA 认证。
那次学习并不是由某个 TiDB 项目推动的。当时，我的日常工作主要围绕医院信息系统和传统关系型数据库展开，接触最多的是 Oracle和MySQL，以及与之配套的 RAC、Data Guard、备份恢复、存储和网络等技术。
在长期以 Oracle 为主的工作环境中，我更习惯从实例、共享存储、集群和主备关系出发理解数据库系统。初次接触 TiDB 时，最先吸引我的也不是某条 SQL 应该怎样编写，而是它为什么要采用这样一套架构。
一条查询进入 TiDB 后，如何由 TiDB Server 完成解析和优化，部分计算又如何下推到 TiKV 或 TiFlash；数据如何按照 Key Range 划分为 Region，并分布在不同的存储节点上；Raft 副本之间如何保持一致，在部分节点故障时继续提供服务；PD 又如何掌握 Region 与 TiKV 节点的分布状态，并完成相应的调度。
这些设计与我熟悉的 Oracle 技术体系有明显区别。Oracle RAC、Data Guard 和 TiDB 都与系统可用性、数据保护或故障处理有关，但它们所处的技术层级不同，解决的问题也不完全相同，很难进行简单的一一对应。
回头看，2022 年的学习更像是在原有知识体系之外，画了一张分布式数据库的基础地图。我开始理解 TiDB Server、PD、TiKV 等核心组件分别承担什么职责，也能看懂数据分布、分布式事务和水平扩展的一些基本概念，但整体仍停留在架构认知层面。
此后的几年里，我的工作重心依然是医院核心业务系统、Oracle 数据库运维、性能问题排查、备份恢复、容灾建设以及相关基础设施保障。TiDB 没有直接进入我的日常运维环境，但早期建立的那张“地图”一直还在。
实际工作做得越久，我越能体会到，只知道某个数据库“支持分布式”或者“可以水平扩容”远远不够。面对真实业务，更需要弄清楚它适合解决什么问题，会带来哪些新的复杂度，应用是否能够适配，现有团队能不能承担后续运维，以及故障发生后业务能否按预期恢复。
2026 年 7 月，我重新系统学习 TiDB，并完成了 PCTP 和 PCSD 的课程与认证。
这一次，我的关注点已经从“TiDB 是什么”，转向了一些更具体的问题：一套 TiDB 集群该如何规划和管理，应用迁移时需要重点检查哪些兼容性问题，原有的数据库运维经验有哪些还能继续使用，以及 TiDB 在医院信息化环境中可能适合哪些场景。
这四年不是连续备考，而是一次间隔后的重新学习。随着工作中遇到的问题越来越具体，我对任何数据库产品的判断也越来越谨慎。
这篇文章记录的，就是我在这段时间里的认知变化。
一、PCTA：先看懂 TiDB 的基本结构
2022 年学习 PCTA 时，我首先需要调整的是观察数据库的角度。
在过去的工作环境中，我更多是从数据库实例内部看问题，例如 SQL 执行、事务、缓存、后台进程、等待事件和数据文件；再通过 RAC、Data Guard、共享存储和备份系统，解决高可用、容灾和数据保护问题。
TiDB 采用了另一种组织方式。
TiDB Server 位于 SQL 层，对外提供 MySQL 协议访问入口，负责连接处理、SQL 解析、查询优化和分布式执行计划生成。它本身不保存业务数据，可以部署多个实例共同对外提供服务。
TiKV 是分布式事务型键值存储引擎。数据按照 Key Range 被划分为 Region，每个 Region 又通过 Raft 机制保存多个副本。PD 则负责管理集群元信息、Region 分布和调度，同时提供分布式事务所需的时间戳服务。
TiFlash 是 TiKV 的列存扩展，主要为分析型查询提供列式存储和计算能力。
理解这些组件之后，我开始把 TiDB 看作一套由 SQL 计算、分布式存储、调度和分析能力共同组成的数据库系统，而不是一台配置更高、容量更大的服务器。
这张“组件地图”大概是我在 PCTA 阶段最实在的收获。它让我开始理解一条业务请求会经过哪些环节，也让我第一次比较系统地关注 Region、副本分布、节点调度和分布式事务时间顺序等问题。
不过，知道组件分别做什么，和真正能管好一套生产集群，完全是两回事。
当时我可以说清楚 TiDB Server、PD 和 TiKV 的基本职责，但对于集群拓扑如何规划、容量如何评估、监控指标怎么看、备份如何验证以及故障如何处理，仍然缺少系统认识。
这也成为后来继续学习 PCTP 的主要原因。
二、为什么在四年后重新学习 TiDB
医院信息系统中的数据库很少是孤立运行的。
HIS、EMR、LIS、医保结算、运营分析和数据交换等业务，通常通过数据库、接口和中间件形成复杂的依赖关系。数据库一旦出现问题，影响的往往不只是某一条 SQL，而可能是一整段业务流程。
一次锁等待，可能让收费、医嘱或结算流程卡住；一次存储延迟，可能表现为多个业务模块同时变慢；一次没有经过实际恢复验证的备份，也可能在真正需要使用时才暴露问题。
在实际运维中，我最常思考的是：数据持续增长后现有架构还能支撑多久？在线交易和复杂报表是否在争用资源？节点、集群或者机房发生故障时，业务应该怎么恢复？备份任务显示成功，到底能不能真正用得上？数据库替换时，应用改造成本又有多高？
这些问题不会因为更换为分布式数据库就自动消失。
分布式数据库可以提供水平扩展、多副本和分布式计算能力，同时也会引入更多组件、更长的请求链路，以及新的网络、热点、调度和一致性问题。DBA 需要理解的不只是操作命令，还要知道故障可能发生在哪一层，又会沿着什么路径影响业务。
因此，2026 年重新开始学习时，我主要想弄清楚几件事：TiDB 集群如何部署、监控、扩缩容和备份恢复；应用能够连上 TiDB，是否就算适配完成；传统数据库中的排障和调优经验还能保留多少；医院哪些场景值得评估 TiDB，哪些场景继续维持现有架构可能更合适。
带着这些问题回到课程里，原来分散的知识点才开始与实际工作建立联系。
三、PCTP：从认识组件到理解集群运维
PCTA 帮我看懂了 TiDB 的整体结构，PCTP 则让我开始关注这套系统应该怎样部署、运行和恢复。
1. 服务启动只是部署工作的开始
刚开始接触数据库部署时，很容易把注意力放在安装命令是否执行成功、组件是否启动、客户端能否连接上。
对分布式数据库来说，这些只能证明软件已经运行。真正开始规划一套集群时，还要考虑组件应该部署多少个、放在哪些节点，副本是否跨越了合理的故障域，计算和存储节点如何分别扩展，访问入口是否存在单点，以及监控、告警、备份和恢复能力有没有同步建设。
TiUP 和 TiUP Cluster 简化了组件安装、集群部署、扩缩容和升级等操作，但它们代替不了拓扑设计和容量规划。
这一点与我维护 Oracle RAC 和 Data Guard 时的体会比较接近。命令执行成功只是操作结果，系统能否长期稳定运行，最终还是取决于架构、资源、故障边界和管理流程。
2. 多副本、高可用、备份和容灾要拆开理解
学习 TiDB 副本机制时，一个很容易混淆的问题是：既然数据已经有多个副本，为什么还需要备份？
在副本配置和拓扑合理、故障没有破坏多数派的情况下，Raft 多副本可以容忍部分节点故障，并维持数据一致性。但如果发生误删除、错误更新、程序缺陷或数据污染，错误也会正常复制到其他副本。
所以，多副本解决不了历史数据恢复问题。
我现在会把这些概念拆开看：多副本主要解决数据冗余和部分节点故障；高可用关注局部组件失效后服务能否继续；备份用于应对数据误删、损坏或污染后的恢复；容灾则要考虑整个集群或机房不可用时，业务按照什么路径切换，以及能否满足既定的 RPO 和 RTO。
TiDB 提供 BR 等备份恢复工具，备份可以保存到 NFS 或受支持的对象存储。但从实际运维角度看，工具只是其中一部分，后面还要继续确认备份周期、保留时间、存储隔离、恢复权限和实际恢复速度。
这一部分与我的日常工作联系最直接。无论使用什么数据库，备份任务成功都只是第一步。最终还是要看备份是否完整、恢复流程能不能执行、恢复后的数据能不能校验，以及恢复时间是否满足业务要求。
3. 排障不能只盯着某一台服务器
传统数据库排查通常会从会话、等待事件、锁、执行计划和主机资源入手。这些思路在 TiDB 中仍然有用，但需要把观察范围扩大。
一条查询先进入某个 TiDB Server，由它完成解析、优化和执行计划生成，部分算子还可能下推到 TiKV 或 TiFlash。最终响应时间也会受到 Region 分布、Leader 位置、热点、网络、磁盘和节点资源的影响。
因此，排查时可以先沿着请求路径看：应用和连接入口是否正常，TiDB Server 的执行计划和算子耗时是否合理，TiKV 或 TiFlash 是否存在处理延迟。与此同时，还要结合 Region、Leader 和热点分布判断，避免把数据倾斜或调度问题误认为单纯的 SQL 问题。
TiDB Dashboard、Prometheus 和 Grafana 提供了比较完整的监控入口。对我来说，更重要的不是记住每一张监控图表，而是逐渐建立这样一种意识：分布式数据库的问题，未必发生在 SQL 所在的那台节点上。
只看 SQL 文本，可能忽略热点和存储抖动；只看某台主机的 CPU，也可能错过执行计划或者数据分布问题。
这部分内容让我原有的排障视角，从单个数据库实例内部，逐渐延伸到一次请求经过的组件和数据路径。
四、PCSD：应用连得上，只是第一步
PCTP 更贴近数据库集群管理，PCSD 则让我重新审视应用和数据库之间的关系。
数据库迁移中，一个很常见的判断是：应用能通过 MySQL 驱动连接 TiDB，主要 SQL 也能执行，迁移就已经完成了大半。
实际上，连接成功只说明协议层基本可用。后面还要继续看 SQL 语法、数据类型、事务行为、自增列和分页逻辑是否符合预期，索引和执行计划能不能扛住压力，ORM、中间件和报表工具是否正常工作。
很多应用还会依赖原数据库的一些专有功能，这些往往是迁移时最容易卡住的地方。
TiDB 对外提供 MySQL 协议，也兼容大部分 MySQL 常用语法和功能，但兼容并不意味着所有行为完全一致。官方文档中仍然列出了部分不支持功能和行为差异。
协议兼容、语法兼容、功能兼容和性能适配，是几个不同的问题。
对于 MySQL、MariaDB 或其他兼容 MySQL 协议的数据源，可以使用 TiDB Data Migration 进行全量迁移和增量同步。但数据能够正常传输，也不能直接说明应用已经可以稳定运行。上游版本、字符集、DDL、数据类型和业务 SQL，仍然需要逐项检查。
医院的一些历史业务系统长期运行在 Oracle 上，可能使用存储过程、序列、触发器、复杂 SQL 和特定数据类型。对这类系统进行数据库替换时，真正需要评估的不只是表能不能建出来。
业务逻辑写在哪里，事务边界怎样划分，程序是否依赖特定锁行为，接口和报表是否使用了专有语法，连接池和 ORM 是否正常，备份、审计和监控工具能否继续使用，这些问题都需要在测试环境中逐步验证。
这类工作也不可能只由 DBA 一个人完成。应用开发、数据库、测试、运维和业务人员都要参与，最终结论应该来自完整测试，而不是几条 SQL 能否执行。
五、从医院信息化场景看 TiDB
目前我参与维护的医院核心业务系统仍然以 Oracle 为主。下面这部分内容，更多是结合现有业务和运维经验，对 TiDB 适用场景的一些思考。
1. 数据增长不一定意味着马上更换架构
医院系统长期运行后，门诊、住院、医嘱、费用、检验、电子病历、接口日志和审计记录等数据都会持续增长。
当数据库容量或性能开始出现压力时，可以采取的办法很多，例如升级服务器和存储、优化 SQL、治理大表、归档历史数据、拆分业务，或者建设独立的数据平台。
TiDB 的分布式存储，以及计算节点和存储节点可以分别扩展的架构，确实提供了另一条技术路径。但是否适合采用，不能只看数据库已经有多少 TB。
更重要的是看单表增长速度、峰值并发、写入热点、事务复杂度、应用改造成本、基础设施条件，以及团队有没有能力维护这套系统。
对于数据规模有限、负载稳定、扩展压力并不明显的系统，传统数据库架构可能更简单，也更容易维护。系统已经运行稳定时，引入新的数据库架构本身也会增加测试、迁移和运维成本。
从医院环境出发，我更倾向于先从边界清晰的新建系统、外围业务或数据增长较快的场景开始评估，而不是直接从最复杂的核心业务入手。
2. TiFlash 对部分实时分析场景有吸引力
医院数据库既要承载挂号、收费、医嘱和结算等在线交易，也要支撑运营统计、医保分析和管理报表。
复杂查询直接运行在交易数据库上，容易与在线业务争用资源；完全依赖离线抽取，又会增加同步链路，并带来数据时效性问题。
TiFlash 是 TiKV 的列存扩展。它通过 Raft Learner 复制 TiKV 数据，为分析型查询提供列式存储和执行能力。
对于需要扫描大量明细数据、同时又对数据时效性有一定要求的场景，这种架构具有吸引力。部分查询可以在同一套 TiDB 集群中使用列存副本，不必全部依赖外部 ETL 和独立分析库。
不过，实际使用时仍然要看哪些表值得建立 TiFlash 副本，数据同步状态是否满足要求，查询能否选择合适的执行引擎，以及分析负载是否会影响其他组件。
TiFlash 也不能简单替代所有数据仓库。实时性、数据规模和查询复杂度不同，适合的技术路径也会不同。
3. 数据库高可用只是业务连续性的一部分
医院业务对连续运行要求较高，但数据库有多个节点，并不代表整套业务系统已经具备持续运营能力。
还需要继续确认应用连接能否自动恢复，数据库访问入口是否存在单点，节点故障时正在执行的事务怎样处理，网络和存储故障是否会同时影响多个节点，备份是否独立保存，以及机房级故障时有没有明确的切换和恢复路径。
人员和流程同样重要。即使产品功能完整，如果长期没有做过切换和恢复演练，真正发生故障时仍然可能卡住。
因此，我在评估数据库架构时，不会只看正常状态下能够提供哪些功能，也会重点看异常发生后，系统和人员能不能按照预定步骤恢复业务。
六、这次学习中，我真正改变了哪些方法
这次准备 PCTP 和 PCSD 时，我一开始仍然会下意识地用 Oracle 或通用 MySQL 经验去判断一些问题。
做完一轮练习后，我发现自己容易出错的并不是 TiDB、PD、TiKV 分别负责什么，而是兼容性边界、默认行为、版本差异，以及几个看起来都说得通的选项。
有些判断放在 Oracle 或 MySQL 的语境中似乎没有问题，回到 TiDB 当前版本文档后却并不成立。特别是 SQL 语法、数据类型、系统变量、DDL 和权限，仅凭印象很容易翻车。
后来，我不再只记录正确答案，而是回头看自己为什么会选错。有的是混淆了产品和组件层级，有的是直接套用了其他数据库的行为，有的是忽略了版本条件，也有的是把可配置行为当成了默认行为。
还有一类错误比较典型：功能名称记住了，但没有真正弄清楚它解决的是什么问题。例如把多副本和备份恢复混在一起，把协议兼容理解成应用已经完成适配。
每遇到一个拿不准的选项，我都会重新查对应的官方文档，确认它描述的是当前版本行为，还是某个特定条件下的结果。
这种方式确实比单纯记答案慢，但也更容易发现自己知识体系里缺的那一块。
后来整理笔记时，我又把内容重新分成了整体架构、Region 与调度、分布式事务、集群运维、监控诊断、备份恢复、数据迁移、SQL 优化和应用兼容性几个部分。遇到新问题时，先判断它属于哪一类，再去找对应组件和使用边界。
回头看三项认证，PCTA 让我建立了 TiDB 的基础架构认知，PCTP 补上了集群部署、监控、扩缩容和备份恢复方面的内容，PCSD 则让我更重视应用行为和兼容性验证。
从 2022 年到 2026 年，我对 TiDB 的认识已经不再停留在组件和产品功能上。现在再看到某项能力时，我会继续追问：它需要什么前提，解决的到底是什么问题，会增加哪些复杂度，放到现有业务里是否合适。
认证提供了一条比较系统的学习路径，但最终留下来的，不只是几项产品知识。更重要的是，在遇到不确定的问题时，知道该去哪里核对，怎样区分概念层级，又怎样把技术能力放回实际业务中判断。
证书记录的是一个学习阶段。查清问题、理解边界，并在工作中做出相对可靠的判断，才是这次重新学习对我更实际的帮助。