第一次听说TiDB的时候，我正被MySQL的分库分表折磨得够呛。业务增长快，数据量一上去，单库顶不住，分库吧，跨库查询、分布式事务、全局ID，哪个坑都得踩一遍。后来看到TiDB的架构图，眼睛一亮——这玩意儿居然能同时兼容MySQL协议，还自带分布式事务和弹性扩展能力，简直是给被分库分表逼疯的人准备的解药。
但真正上手TiDB之后才发现，它跟MySQL的“兼容”更像是个温柔的陷阱。你用MySQL的思维去写SQL，大概率没问题，可一旦数据量上来，性能瓶颈的排查思路就完全不同了。TiDB的SQL层（TiDB Server）负责解析和优化，存储层（TiKV）负责实际数据，两层分离意味着你不能再像调MySQL那样只看慢查询日志，还得关注TiKV的Region分布、热点问题、甚至Raft副本的同步状态。我第一次遇到慢查询，习惯性地去看执行计划，发现TiDB给出的执行计划跟MySQL的差别巨大——它多了个“分布式执行”的概念，有些算子会下推到TiKV并行计算，有些则必须拉回TiDB Server处理。这一步没理解透，后面的调优全是瞎忙活。
说到高可用，TiDB的设计思路确实干净利落。TiKV底层用Raft协议做多副本同步，默认三副本，任何一个节点挂了，另外两个副本能自动选举出新的Leader，应用层几乎无感知。我做过一次故障演练，直接kill掉一台TiKV节点，业务侧只看到几个连接被重置，重连后一切正常，数据一条没丢。这种体验在传统MySQL主从架构里根本不敢想——主库挂了得手动切换，从库延迟高还得担心丢数据。不过TiDB的高可用不是白来的，它要求至少三个TiKV节点才能形成高可用集群，而且节点之间的网络延迟得控制好，跨机房部署时Raft同步的延迟会直接影响写入性能，这个取舍得提前想清楚。
实际部署TiDB的时候，硬件规划和集群拓扑的学问比想象中多。官方推荐的配置是TiDB Server和PD（Placement Driver）放一起，TiKV单独部署——因为PD负责整个集群的调度，包括Region的分配、负载均衡、故障转移，它要是性能跟不上，整个集群都会受影响。我第一次做集群规划时图省事，把所有组件塞在同一批机器上，结果业务高峰期PD的CPU飙到80%多，TiKV的写入延迟跟着涨。后来老老实实按官方建议拆开部署，问题才缓解。存储方面，TiKV强烈建议用SSD，机械硬盘在随机读写场景下根本扛不住Raft日志的频繁写入。另外TiKV的数据目录和Raft日志目录最好分开挂载，避免I/O争抢，这些都是踩过坑才明白的细节。
数据迁移这块，TiDB提供了不少工具，但每个工具都有自己的脾气。全量迁移用DM（Data Migration）或者Dumpling+Mydumper都行，增量同步就得靠TiCDC了。我踩过最大的坑是DM的同步延迟——源库写入量大时，DM的单线程同步模式根本追不上，导致目标库的数据滞后严重。后来发现DM支持开启并行同步，把表按主键哈希分到多个线程去处理，延迟才降下来。TiCDC的坑更隐蔽，它默认只同步已提交的事务，而且对DDL的支持有版本限制，某些特殊DDL（比如带online ddl hint的）可能同步不过去。所以生产环境做迁移前，建议先在测试环境把真实的表结构和数据量跑一遍全流程，别信工具文档里说的“全自动”。
TiDB的运维监控体系是我见过最像“全家桶”的。Prometheus+Grafana是标配，官方提供的监控面板里有几百个指标，刚开始看简直头皮发麻。但实际运维时真正要盯的就那几个：TiKV的CPU使用率、Region数量、Leader分布均衡度、写延迟的P99值。我习惯每天上班第一件事看TiKV的“热点Region”面板——如果某个Region的读写量明显高于其他，说明数据分布出了问题，可能是业务写入有固定模式，比如只往最新时间段的表里写数据。这时候可以用TiDB的Split Region功能手动把热点Region拆开，或者调整表的Shard Row ID Bits参数让写入分散到更多Region。这套玩法跟MySQL的“分区表”有点像，但粒度更细，也更动态。
高可用架构的进阶玩法是跨机房容灾。TiDB的Raft天然支持跨机房部署，但有个参数叫“label”需要配置好——每个TiKV节点打上机房标签后，PD调度时才会尽量把副本分散到不同机房。我见过有人没配label，三副本全落在同一个机架里，机房断电直接全挂。配置好label之后，还需要设置“隔离级别”，比如要求每个副本所在的机房不同，这样即使整个机房故障，其他机房的副本也能顶上。不过跨机房部署有个绕不开的成本：Raft的日志同步需要跨机房网络，延迟可能从0.1ms涨到5ms以上，写入性能会明显下降。所以跨机房方案一般用在强一致性要求极高的核心业务上，普通业务还是单机房多副本更划算。
TiDB的生态工具链也在不断完善，但有些东西还是得自己摸。备份恢复用BR（Backup & Restore）工具，支持全量备份和日志备份，恢复时可以做到秒级时间点恢复（PITR），这个功能在MySQL生态里几乎不可想象。但BR的备份文件是逻辑备份，恢复时对目标集群的版本要求很严格，跨版本恢复经常失败。TiDB Lightning用于批量导入数据，速度确实快，但它在导入过程中会占用大量TiKV资源，生产环境得选业务低峰期操作。至于TiDB的SQL调优，除了看执行计划，还得善用Index Merge和MPP（Massively Parallel Processing）模式——后者在处理大表关联查询时能把计算下推到多台TiKV并行执行，性能提升是数量级的，但前提是表必须按TiDB的方式正确分区。
回到开头说的那个核心问题：TiDB到底适合什么场景？我的经验是，如果你的业务数据量到了单表千万级甚至亿级，查询模式复杂，又不愿意做分库分表，那TiDB值得认真考虑。但它不是银弹——小数据量场景它就是杀鸡用牛刀，运维成本比MySQL高不少；强事务场景虽然TiDB支持ACID，但分布式事务的性能损耗摆在那里，跟单机数据库没法比。选TiDB就像选车，你得清楚自己是要跑高速的长途车还是市区代步的小车。TiDB这辆车，跑长途、载重货确实稳，但如果你只是每天上下班十几公里，真没必要开它。关键还是得摸清楚自己的业务脾气，别被“分布式”“高可用”这些词给忽悠了。
