写在前面作为一个制造业数字化团队的开发负责人我最怕听到的一句话就是“数据库又慢了”。MOM 平台上线 4 年数据量从最初的几百 G 涨到几个 T。每次月底报表、跨工厂查询系统就开始”喘气”。加索引、拆表、优化 SQL……这些招数用了个遍但增长瓶颈还是如期而至。2026 年春节前我们把核心数据库从 MySQL 5.7 迁移到了 TiDB 8.0。这篇文章讲讲我们为什么做这个决定以及真实的迁移体验。一、痛点MySQL 时代我们遇到了什么1.1 分库分表的困境随着业务增长单机 MySQL 的三个老问题越来越突出问题具体表现我们的应对存储瓶颈数据量突破 2TB磁盘告警频繁删历史数据、压缩表空间查询变慢跨工厂报表查询耗时 30秒加缓存、加索引并发受限连接数经常打满连接池优化、读写分离最痛苦的是跨工厂数据汇总。我们是集团中心化主从部署月底汇总报表时要跨库查询效率极低。1.2 分库分表不是答案团队曾讨论过分库分表方案但评估后放弃了改造成本高业务代码需要大量改造SQL 写法受限运维复杂度跨库事务、分布式 ID、扩容迁移都是坑查询灵活性差跨分片查询支持有限难以应对业务变化当时我们就在想有没有一种方案能让我们像用单机数据库一样简单同时又具备分布式的能力二、选型为什么是 TiDB2.1 我们的选型标准维度核心要求兼容性最好不改代码平滑迁移扩展性支持水平扩展能应对未来至少 3-5 年增长HTAP 能力同时支持事务和分析查询高可用数据多副本容灾不再担心单点故障运维成本不能引入过高的学习和维护成本2.2 TiDB 打动我们的三个点1. 兼容 MySQL应用改造成本近乎为零TiDB 兼容 MySQL 5.7⁄8.0 协议我们现有的 JDBC 连接池、MyBatis、Navicat 等工具都能直接使用。这点太重要了——不需要重写一行业务代码。2. 水平扩展不再为扩容发愁TiDB 的架构天然支持水平扩展加机器就能扩展性能不需要手动分库分表数据自动均衡3. HTAP 能力一个数据库搞定所有场景以前我们的架构是MySQL业务 额外数据分析系统 T1 数据同步。现在 TiDB 一套系统同时支持 OLTP在线事务和 OLAP在线分析告别”数据库 ETL”和”T1”交易与分析毫秒同步。2.4 权威数据说话选型不能只靠感觉TPC-C 基准测试给我们吃了定心丸指标MySQLTiDB提升tpmC核心指标9,56035,4472.7 倍总吞吐量21,24578,9552.7 倍2.5 同行验证不只是我们在用这些企业都在生产环境跑 TiDB制造业小米、顺丰、蔚来汽车互联网美团、腾讯、京东金融业中国平安、华泰证券、微众银行这么多头部企业验证过我们心里更有底了。2.3 三年备库验证是骡子是马拉出来遛遛其实我们不是冲动决策。TiDB 作为备库已经运行了 3 年2023 年搭建 TiDB 集群作为数据灾备2024 年测试环境切换到 TiDB稳定运行近 1 年2025 年开始规划生产环境迁移充分的验证期是我们敢在生产环境动手的底气。三、迁移平滑切换是怎么做到的3.1 核心策略零感知 快速回滚迁移最大的风险不是技术而是业务中断。我们的策略是原则实现方式平滑过渡TiDB 作为备库同步 3 年数据已验证最小停机计划停机窗口 1.5 小时快速回滚TiCDC 实时同步回滚时间 15 分钟3.2 迁移时间线 2026年2月9日 春节前 11:00 - 停机开始 ↓ - 关闭业务流量网关限流 - 停止定时任务 - 确认数据同步状态 ↓ 11:30 - 数据迁移 ↓ (90分钟停机窗口) 12:30 - 迁移完成系统恢复 ↓ 13:00 - 功能验证通过3.3 升级步骤149 个动作一个都不能少别看切换那天只停了 90 分钟背后是精心准备的 149 个升级步骤准备阶段提前一周通知、部署新 Nacos 集群、配置 CDC 反向同步、16 个业务库账号权限预配切换阶段Jenkins 流水线逐服务部署、关闭网关流量、停止定时任务、数据同步验证验证阶段APS/MES/WMS 核心模块冒烟测试、TiCDC/Redis 集群状态监控3.4 回滚方案15 分钟内可恢复我们做了最坏的打算——16 个回退关键步骤步骤操作耗时1. 再次通过 Nginx 关闭服务入口约 1-2 分钟2. 停止所有应用服务确保 TiDB 无新数据写入约 1-2 分钟3. 暂停 TiCDC 同步任务改回 MySQL 数据源约 3-5 分钟4. 按顺序重启应用服务连接 MySQL约 5-8 分钟5. 发布恢复通知即时目标15 分钟内恢复业务。虽然最后没派上用场但演练过的方案让我们心里有底。3.5 真实体验比预想中顺利迁移过程有几个超出预期的点应用无需改动数据源配置一切换就 OK原有 SQL 全部兼容停机时间比预想短原计划 90 分钟实际 60 分钟搞定回滚方案没派上用场但演练过确保有备无患四、收益迁移半年后效果如何4.1 性能提升指标迁移前迁移后提升跨工厂复杂报表查询30秒8秒~4倍4.2 成本变化成本项变化说明存储成本-30%TiDB 压缩率优于 MySQL运维成本持平团队学习成本已消化硬件投入长期看降低水平扩展避免频繁换服务器4.3 能力提升不再怕数据增长存储不够加节点就行实时分析成为可能业务可以随时跑 adhoc 查询高可用有保障基于 Raft 协议数据多副本实时同步实现 RPO0 和秒级 RTO备份能力升级支持物理备份和 PITR时间点恢复两地两中心建设成为可能AI 友好内置向量支持为未来的 DataAI 应用铺路五、总结给准备迁移团队的建议5.1 什么情况下可以考虑 TiDB数据量超过 1TB单机 MySQL 开始吃力有复杂的跨库查询和分析需求不想自己维护分库分表方案对 HTAP 能力有需求事务分析一体化5.2 我们的建议建议说明充分验证先在测试环境跑 3-6 个月再考虑生产选好时机选业务低峰期我们选的是春节前回滚方案一定要有并且要演练团队学习提前安排 TiDB 运维培训5.3 一点感悟数据库选型没有最优解只有最适合。我们的选择不一定适合所有人但核心思路是相通的用真实的业务痛点驱动决策用充分的验证降低风险。互动时间你们团队现在用的是什么数据库有没有遇到类似的瓶颈