一、缘起：当业务撞上数据库的“天花板”
我长期负责公司项目业务系统的数据库运维工作，日常打交道最多的就是MySQL。随着业务持续迭代，平台数据体量稳步激增，高并发读写、实时报表统计等需求日益常态化，传统MySQL架构的短板彻底暴露。
最直观的问题是扩容能力受限。核心业务单表数据突破2000万行后查询延迟陡增，我们尝试了分库分表方案，但随着分片数量增加，每次扩容都需要停机迁移数据，运维成本极高。其次是混合负载冲突——业务既要支撑高并发实时交易，又需要实时数据分析，原有“主从分离”模式下，分析SQL会直接拖垮交易库。更麻烦的是，跨分片事务一致性难以保障，线上偶尔出现数据错乱的问题。
团队内部讨论过几种方案：继续加码MySQL分库分表、迁移到云托管数据库、或者选择一款原生分布式数据库。经过多轮对比，我们最终锁定了TiDB。
二、选型：为什么是TiDB？
选型决策并非拍脑袋，而是基于真实业务场景的刚需驱动。TiDB打动我们的核心优势有三点：
第一，MySQL高度兼容，迁移成本极低。 TiDB完整兼容MySQL协议和SQL语法，存量业务几乎无需大规模改造即可迁移。这对我们来说是决定性的——避免了大规模重构的风险。
第二，HTAP一体化架构。 TiDB行存TiKV支撑高并发交易，列存TiFlash实时同步副本，一套集群就能同时承载OLTP和OLAP负载。这意味着我们不再需要单独搭建离线数仓，彻底砍掉了冗余的ETL链路。
第三，存算分离、在线扩缩容。 计算节点TiDB和存储节点TiKV可以独立弹性扩容，增减节点不中断业务。对业务数据持续增长、流量波动大的我们来说，这简直是刚需。
三、学习：从理论到实践的系统化进阶
选型确定后，我为自己制定了系统化的学习计划。
第一步是建立全貌认知。 我先通过官方《TiDB快速起步》课程，在短时间内对TiDB的整体架构、核心特性和应用场景建立了全局认识。
第二步是深入架构原理。 我重点研读了TiDB的架构分层——TiDB Server、PD、TiKV、TiFlash，吃透了Raft日志复制、Region分裂与调度、MVCC与事务模型。这个阶段最大的收获是一种“分布式原生”的思维转变——不再把数据库当作单点黑盒，而是可以精细化控制数据分布和算力。
第三步是动手实操。 我用TiUP在本机模拟生产拓扑部署集群，做TPCC和Sysbench压测。还故意触发节点宕机，观察PD自动恢复能力。实践让我明白：分布式系统的每个操作都需要谨慎评估。
四、备考：PCTP认证与踩坑实录
系统学习后，我报名了PCTP认证（TiDB数据库专员）。PCTP考试共5共 50 题，含单选、多选题，每题 2 分，满分 100 分。考试通过分数为 60 分，PCTP与PCTA最大区别是：PCTP考试的内容更深入、更贴近现实工作内容。
备考过程我踩了两个坑。第一个坑是只看视频不看文档。 很多细节考点都在官方视频课程里但不全，只看文档又缺乏逻辑关联性，且知识点多。后来我用1.5倍速刷完官方课程，逐题拆解课后习题。第二个坑是理论脱离实操。 备考期间我在测试环境安装一个极简TiDB集群，港看完视频后觉得会了，反正照搬。当过两天范围这种操作目的是干什么的时候就好卡壳了，因此在实操过程中得多问自己几个问什么，这样可用加深理解。
最终我顺利通过了PCTP认证。回头看这段经历，收获的远不止一张证书——更重要的是对分布式数据库的系统性认知。
从最初接触TiDB到完成选型、系统学习、拿下认证、将来要推进落地，这条路走下来，最大的感悟是：技术选型不能跟风，一切要以真实业务痛点为核心。TiDB不是“大号MySQL”，而是一套需要分布式思维驾驭的数据平台-。掌握它带给我的不仅是解决业务问题的硬实力，更是一次技术视野的全面升级。