做电商后端的同学应该都深有体会：MySQL 分库分表能救一时，但救不了一辈子。
随着订单数据量持续上涨，分片越来越多、扩容越来越重、跨表统计越来越慢。我所在的生鲜电商团队，此前订单系统长期使用 8库64表 Sharding-JDBC 分片架构，稳定跑了三年，但从去年开始，大促限流、报表延迟、运维爆炸的问题集中爆发。
经过多轮 POC 对比，我们最终彻底放弃传统分库分表方案，将核心订单业务整体迁移到 TiDB 7.5 HTAP 集群，实现了：单逻辑表承载百亿数据、无需分片、联机交易+实时报表一套集群搞定。
本文是真实线上迁移落地复盘，包含完整迁移方案、性能对比、生产踩坑和成本收益，无水文、无套话，可直接作为中小公司 TiDB 落地参考。
一、为什么我们彻底放弃了 MySQL 分库分表？
先讲真实线上现状，不夸大、不渲染。
我们订单系统日常日单量百万级，大促峰值单日可达3000万+，三年累计数据 18亿+、2.1TB。原有 64 张子表，单表数据量早已突破亿级。
这套架构的痛点已经不是“慢”，而是严重阻碍业务迭代：
1. 扩容成本极高
传统分片扩容需要拆实例、拆表、改路由、回归验数据，一次扩容流程走完至少一周。去年618前夕分片容量告急，来不及扩容只能临时限流，直接影响成交。
2. 实时统计完全无法支撑
运营日报、销量统计、区域GMV全部需要跨64表 UNION 聚合。MySQL 根本扛不住，只能凌晨离线跑批，业务拿到的数据永远是 T+1。
我们曾用 MySQL+ES 做实时查询，但是字段变更、数据同步、运维复杂度大幅上升，非常笨重。
3. 运维负担爆炸
64 张表的备份、巡检、索引优化、慢 SQL 排查，工作量是单表的数倍，DBA 大量精力消耗在重复分片运维上。
基于以上问题，我们明确了新架构的核心诉求：
- 无需人工分表，天然分布式扩容
- 兼容 MySQL，业务代码尽量不动
- 一套集群同时支撑交易 + 实时分析
- 高可用、低运维成本
最终选型 TiDB，完全贴合我们的业务场景。
二、生产集群部署架构（真实线上配置）
我们采用物理机自建集群，稳定度更高，适合核心交易业务。
- PD 3节点：负责元数据调度、分片均衡
- TiDB 4节点：计算层，承接业务读写请求
- TiKV 6节点（三副本）：事务存储，承载核心订单写入、查询
- TiFlash 3节点：列式存储，专门用来跑报表、统计、OLAP 查询
核心优势：一份数据、双引擎复用。联机走 TiKV 行存，分析走 TiFlash 列存，互不抢占资源。
三、MySQL 到 TiDB 完整迁移方案（零停机、灰度安全）
我们采用业内最稳妥的方案：Lightning 全量冷导入 + DM 增量同步 + 灰度切流，全程不影响原线上业务，无停机窗口。
1. 前置兼容性排查
迁移前必须做兼容性校验，否则上线必翻车。我们通过官方工具扫描，主要处理三类问题：
- 废弃复杂存储过程，统一下沉到业务代码
- 所有表统一 InnoDB、规范主键结构
- 去掉 MySQL 分区表，改用 TiDB 天然分片替代
重点规范：所有核心表必须有主键，杜绝隐式 _rowid 热点。
2. 全量历史数据导入
针对 2.1TB 海量历史数据，我们使用 Dumpling 导出 + Lightning 本地模式导入。
这里是 TiDB 最香的一点：MySQL 64 张子表，直接合并为 TiDB 一张逻辑大表。彻底告别分片逻辑。
整个全量导入耗时约 11 小时，放在凌晨低峰窗口完成，对业务无感知。
3. DM 增量实时同步
全量数据对齐后，搭建 DM 同步 Binlog，保持 MySQL 与 TiDB 数据实时一致。
初期同步延迟 10–30s，优化 TiKV 队列与批量参数后，稳定延迟 500ms 以内，完全满足交易业务一致性要求。
4. 三级灰度切流（核心上线策略）
为保证绝对安全，我们采用阶梯式灰度：
- 只读灰度：10% → 50% → 100% 切读流量，观察慢 SQL、延迟、CPU、GC
- 双写灰度：业务同时写 MySQL、TiDB，定时对比数据一致性
- 全量切换：确认 24h 数据零差异，彻底下线 MySQL 分片架构
业务侧零代码改造，仅修改 JDBC 连接地址与参数，极大降低上线风险。
四、上线后真实性能对比（生产实测）
1. 交易性能提升明显
- 下单 TP99 延迟：320ms → 78ms，降低 75%+
- 大促峰值承载：4.2w 限流 → 5.5w 稳定无限流
- DDL 变更：从几小时跨表变更 → 秒级在线 DDL
2. 报表能力质变
原 MySQL 跨表统计：30 分钟+，只能 T+1 离线跑批。
TiDB + TiFlash 之后：同款 SQL 1s 级返回，实时当日经营数据。
我们直接下线了整套 ES 报表架构，每年节省不少机器与运维成本。
五、生产真实踩坑总结（非常实用）
这里分享几个我们真实踩过、全网高复用的坑。
1. 自增主键导致写入热点
初期沿用 MySQL 自增 ID，大促集中写入全部打在同一个分片，单节点 CPU 跑满。
解决方案：业务主键统一改为AUTO_RANDOM，数据自动打散，热点彻底解决。
2. 未开启批量写入参数，性能极差
没有配置 rewriteBatchedStatements，批量入库效率极低。开启后批量写入性能提升数倍，属于生产必配参数。
3. 全量表开启 TiFlash 导致磁盘压力大
并非所有表都需要列存副本。优化后：仅报表、统计类表开启 TiFlash，流水日志表关闭，磁盘压力大幅下降。
4. 上游大 DDL 容易导致 DM 同步异常
规范流程：上游 MySQL DDL 变更，先在 TiDB 预执行，再变更源端，避免同步中断。
六、迁移后的整体收益
- 研发效率提升：彻底告别分表规则设计，迭代速度明显加快
- 运维压力减半：64 表运维简化为单逻辑表运维
- 硬件成本下降：下线大量 MySQL、ES 节点，整体 TCO 下降 30%+
- 业务能力升级：具备实时经营分析能力，支撑精细化运营
七、总结
这次迁移最大的感受是：MySQL 分库分表是“被动填坑”，TiDB 是“架构升级”。
对于中小电商、互联网业务，只要数据量达到单表亿级、有冷热混合读写、有实时统计需求，TiDB 的 HTAP 架构优势非常明显。不用再为分片扩容熬夜、不用再维护笨重的辅助查询组件、不用再忍受 T+1 的滞后数据。
技术选型从来不追新，只选合适的。TiDB 不是万能的，但在替代 MySQL 分库分表、一套架构支撑交易+实时分析的场景下，是目前最稳、最落地的选择。