写在前面
作为一个制造业数字化团队的开发负责人，我最怕听到的一句话就是："数据库又慢了"。
MOM 平台上线 4 年，数据量从最初的几百 G 涨到几个 T。每次月底报表、跨工厂查询，系统就开始"喘气"。加索引、拆表、优化 SQL......这些招数用了个遍，但增长瓶颈还是如期而至。
2026 年春节前，我们把核心数据库从 MySQL 5.7 迁移到了 TiDB 8.0。这篇文章，讲讲我们为什么做这个决定，以及真实的迁移体验。
一、痛点：MySQL 时代我们遇到了什么？
1.1 分库分表的困境
随着业务增长，单机 MySQL 的三个老问题越来越突出：
| 问题 | 具体表现 | 我们的应对 |
|---|---|---|
| 存储瓶颈 | 数据量突破 2TB，磁盘告警频繁 | 删历史数据、压缩表空间 |
| 查询变慢 | 跨工厂报表查询耗时 30秒+ | 加缓存、加索引 |
| 并发受限 | 连接数经常打满 | 连接池优化、读写分离 |
最痛苦的是跨工厂数据汇总。我们是集团中心化主从部署，月底汇总报表时要跨库查询，效率极低。
1.2 分库分表不是答案
团队曾讨论过分库分表方案，但评估后放弃了：
- 改造成本高：业务代码需要大量改造，SQL 写法受限
- 运维复杂度：跨库事务、分布式 ID、扩容迁移都是坑
- 查询灵活性差：跨分片查询支持有限，难以应对业务变化
当时我们就在想：有没有一种方案，能让我们 像用单机数据库一样简单 ，同时又具备 分布式的能力？
二、选型：为什么是 TiDB？
2.1 我们的选型标准
| 维度 | 核心要求 |
|---|---|
| 兼容性 | 最好不改代码，平滑迁移 |
| 扩展性 | 支持水平扩展，能应对未来至少 3-5 年增长 |
| HTAP 能力 | 同时支持事务和分析查询 |
| 高可用 | 数据多副本容灾，不再担心单点故障 |
| 运维成本 | 不能引入过高的学习和维护成本 |
2.2 TiDB 打动我们的三个点
1. 兼容 MySQL，应用改造成本近乎为零
TiDB 兼容 MySQL 5.7⁄8.0 协议，我们现有的 JDBC 连接池、MyBatis、Navicat 等工具都能直接使用。这点太重要了------不需要重写一行业务代码。
2. 水平扩展，不再为扩容发愁
TiDB 的架构天然支持水平扩展：
- 加机器就能扩展性能
- 不需要手动分库分表
- 数据自动均衡
3. HTAP 能力，一个数据库搞定所有场景
以前我们的架构是：MySQL（业务）+ 额外数据分析系统 + T+1 数据同步。现在 TiDB 一套系统同时支持 OLTP（在线事务）和 OLAP（在线分析），告别"数据库 + ETL"和"T+1"，交易与分析毫秒同步。
2.4 权威数据说话
选型不能只靠感觉，**TPC-C 基准测试**给我们吃了定心丸：
| 指标 | MySQL | TiDB | 提升 |
|---|---|---|---|
| tpmC（核心指标） | 9,560 | 35,447 | 2.7 倍 |
| 总吞吐量 | 21,245 | 78,955 | 2.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 协议，数据多副本实时同步，实现 RPO=0 和秒级 RTO
- 备份能力升级 ：支持物理备份和 PITR（时间点恢复），两地两中心建设成为可能
- AI 友好：内置向量支持，为未来的 Data+AI 应用铺路
五、总结：给准备迁移团队的建议
5.1 什么情况下可以考虑 TiDB？
- 数据量超过 1TB，单机 MySQL 开始吃力
- 有复杂的跨库查询和分析需求
- 不想自己维护分库分表方案
- 对 HTAP 能力有需求（事务+分析一体化）
5.2 我们的建议
| 建议 | 说明 |
|---|---|
| 充分验证 | 先在测试环境跑 3-6 个月，再考虑生产 |
| 选好时机 | 选业务低峰期，我们选的是春节前 |
| 回滚方案 | 一定要有，并且要演练 |
| 团队学习 | 提前安排 TiDB 运维培训 |
5.3 一点感悟
数据库选型没有最优解，只有最适合。我们的选择不一定适合所有人，但核心思路是相通的：
用真实的业务痛点驱动决策，用充分的验证降低风险。
互动时间
你们团队现在用的是什么数据库？有没有遇到类似的瓶颈？