搬去TiDB这事，我们团队当初纠结了小半年。MySQL用了快八年，数据量冲破几个T之后，单机主从那套玩法越来越吃力。半夜大查询把从库拖垮，主从延迟飙到几千秒，业务方凌晨两点打电话来问报表怎么又卡了。换库是大手术，谁都不敢拍胸脯。但撑着也不是办法，磁盘要加，性能上不去，运维天天救火。定下来，与其在MySQL上缝缝补补，不如认真评估一次TiDB迁移。这个决定不轻松，但回头看，准备功夫做足了，真正落地反倒比想象中顺。
第一步先摸底，这步省不得。我们把所有业务系统过了一遍筛子，按读写比、数据量、并发峰值、一致性要求分了四档。核心交易库和支付流水这种强一致、高并发的，属于最高优先级；日志分析、报表查询这类可以接受秒级延迟的，排后面。每个库的表结构、索引情况、大字段占比都得统计清楚。有个细节特别容易忽略——TiDB对自增主键有分布式瓶颈，我们有两张表用自增ID做主键，单表过亿行，这种就得提前改成雪花ID或者联合主键。摸底不是走形式，是给后面所有决策打地基，地基歪了，后面全是坑。
选迁移方案的时候，我们对比了三条路。全量导出再导入，适合一次性搬迁、业务能停的；数据同步工具做增量，适合双跑阶段；逻辑备份加回放，适合跨版本大升级。我们最终选了TiDB官方的DM（Data Migration）加Dumpling组合。Dumpling负责全量导出，比mysqldump快不少，并发导出还能断点续传；DM做增量同步，把业务切换前的binlog持续追平。这里有个关键点——先全量，再开增量，全量导完那一刻记录binlog位点，然后增量从那个点开始追。我们踩过一个坑，顺序搞反了，增量先跑起来，全量导出的数据一恢复，两边冲突，主键全重复，白折腾一晚上。
迁移过程中的双跑阶段，最考验耐心。我们做了整整两周的双写验证，业务流量同时打到MySQL和TiDB，然后定时比对两边数据。比对工具自己写的，按表分批查checksum，一天跑三轮。头两天问题不少，主要是字符集和时区设置不一致，导致部分时间字段差八个小时。还有几个存储过程，MySQL写法在TiDB里不兼容，TiDB对存储过程支持有限，得改成应用层实现。双跑阶段别急着切流量，宁可多验证几天，也别上线后出幺蛾子。我们有个兄弟团队就是只跑了三天就切，结果月末对账发现少了几十万条记录，回滚又花了两天，得不偿失。
正式切换那天，我们按预案一步步来。先停写操作，应用层做个只读开关，把MySQL设为只读，DM把一段增量追平，确认两边数据一致。然后改应用连接串，指向TiDB，再开写流量。整个过程控制在十五分钟以内，业务感知就是一次短暂闪断。这里有个小技巧——连接串不用改代码，配置中心直接推送，灰度发布平台按集群分批切，先切非核心业务，观察半小时再切核心交易。我们切完核心库那十分钟，心跳监控曲线平得跟心电图正常似的，群里一片欢呼，但我知道真正的考验还在后面。
上线后的性能调优才是持久战。TiDB的架构跟MySQL完全不同，以前那套优化思路得推翻重来。MySQL靠的是buffer pool命中率，TiDB更吃计算节点和存储节点的资源配比。我们第一周就发现，几个原本在MySQL上跑得飞快的复杂JOIN，在TiDB上反而慢了三倍。排查下来，是执行计划没走对索引，TiDB的优化器对统计信息依赖很强，得手动跑ANALYZE TABLE更新统计信息。另外TiDB的并行度设置也很讲究，tidbdistsqlscan_concurrency调太高，会把存储节点CPU打满，反而拖慢整体。调了一个月，把慢查询从日均两百多条压到个位数，这过程比迁移本身还磨人。
给还没上车的人一句实在话——TiDB迁移不是技术问题，是管理问题。技术方案再完美，业务方不配合、窗口期定不下来、回滚预案没人演练，照样翻车。我们每周跟业务方开一次对齐会，把迁移进度、风险点、验证结果同步清楚，让业务方知道每一步在干什么、为什么要这么干。尤其是双跑阶段，业务方会觉得“既然两边都在跑，是不是可以提前切”，这种时候得顶住压力，把数据比对的差异记录摆出来，用事实说话。迁移不是百米冲刺，是接力赛，每一棒交接都得稳。
TiDB迁移这条路，我们从规划到稳定运行，前后花了将近四个月。现在的扩容痛点，水平扩展加自动分片，加节点就像加内存一样简单，半夜大查询也不怕拖垮从库了。但迁移本身没有银弹，该踩的坑一个不少，只是提前踩了，后面就顺了。如果你也在考虑TiDB迁移，记住这句话——规划时多花一倍时间，落地时省三倍力气。把每个环节想透，把每个风险列全，剩下的就是按部就班执行。
