我们公司MES生产执行系统，基于MySQL分库分表架构稳定跑了整整五年，全面覆盖车间工单、工序流转、质检记录、物料出入库全生产链路。
项目初期业务体量小、数据量有限，我们采用MySQL 8.0 + Sharding-JDBC方案，搭建4库48张水平分表，完全能支撑当时的业务需求。
但随着集团三大生产基地全面扩建，12条自动化产线7×24小时不间断投产，日均新增生产数据800万条、累计16亿条、数据总量1.8TB。曾经够用的分片架构，开始暴露出扩容难、统计慢、运维重、改造成本高的一系列致命问题，逐渐拖慢整体数字化迭代节奏。
经过多轮POC压测、灰度试运行、故障模拟验证，我们最终下定决心：彻底抛弃MySQL分库分表，全量迁移至TiDB 8.0 HTAP分布式集群。
改造后实现一张逻辑表承载百亿级生产数据，一套集群同时支撑线上高并发交易 + 实时报表分析，支持在线无损扩容，彻底告别人工拆表、分片运维的痛点。
今天把整套踩坑经验、迁移方案、架构对比、性能收益完整复盘出来，做MES、工厂数字化、ERP系统的同行，可以直接参考落地。
一、复盘：MySQL分片架构，为何撑不住智能制造高并发场景？
先说说我们旧架构的现状：4库48张水平分表，按工厂编号分片，稳定运行4年后，随着产线翻倍、数据暴增，所有隐性问题集中爆发，严重影响生产业务。
1. 扩容极其繁琐，业务高峰期只能限流降本
传统分片架构扩容，绝非简单加服务器这么简单。
每次新增分厂、新增自动化产线，都需要：新增分片实例 → 修改代码路由规则 → 全量迁移历史数据 → 全链路回归测试，整套流程走完至少8天。
去年新车间投产前夕，原有分片存储空间即将耗尽，来不及完成完整扩容流程，我们只能临时限制产线实时数据上报。直接导致车间生产大屏延迟2小时，管理层无法实时查看良率、设备OEE、产能进度，对生产调度造成极大影响。
2. 跨分片统计只能T+1离线跑批，实时看板彻底失效
工厂核心报表：月度产能、产品良率、设备OEE、物料消耗核算，全部需要跨48张子表聚合查询。
但MySQL多表联查聚合效率极低，单份报表跑完需要40分钟以上，只能放在凌晨低峰期离线执行。这就导致业务部门永远只能看昨天的数据，无法根据当日生产情况调整排产、调配物料、优化产能。
为了解决实时查询问题，我们曾搭建MySQL + ClickHouse双存储架构，但两套集群的数据同步、字段对齐、索引维护、故障排查，直接让运维工作量翻倍，硬件成本也同步暴涨，治标不治本。
3. 分片运维重复且繁重，占用DBA大量精力
48张子表相互独立，巡检、索引优化、慢SQL排查、分库备份、碎片清理，全部需要逐表操作。
之前团队每周至少2天时间耗费在机械重复的分片运维上，根本没有精力做性能优化、架构升级、业务赋能等核心工作。
4. 表结构变更风险高、周期长，无停机窗口可用
产线全年无停机维护窗口，MySQL跨分片新增字段、新增索引，需要逐张表循环执行。48张表完整变更一次需要3小时，只能挤在每月深夜极小窗口操作，一旦出错直接影响整条产线数据上报，风险极高。
二、新架构选型：我们为什么坚定选择TiDB 8.0？
结合制造业MES真实场景，我们对新数据库定下4个硬性刚需，缺一不可：
• 原生分布式：无需人工分库分表，支持在线横向无损扩容
• 高兼容MySQL：现有Java MES代码改动极小，降低改造成本
• HTAP混合负载：一套集群同时扛高并发交易 + 海量统计分析
• 高可用稳定：多副本机制，单节点故障不中断产线数据上报
经过多轮竞品对比、压测验证，TiDB 8.0完全匹配所有需求，我们正式启动全量架构迁移项目。
三、生产级TiDB集群部署架构（适配中型制造企业）
本次采用物理服务器自建集群，核心设计：交易负载与分析负载物理隔离，杜绝报表查询挤占线上生产写入资源，架构配置如下：
• PD调度节点（3台 8核16G）：负责集群元数据管理、Region均衡、全局调度
• TiDB计算节点（4台 16核32G）：承接MES所有读写SQL、生产事务请求
• TiKV存储节点（8台 24核64G + SSD）：三副本存储，承载产线24小时高并发写入、工单/质检/物料核心交易数据
• TiFlash列存节点（3台 16核64G）：专门负责OLAP聚合统计，支撑产能、良率、OEE、库存实时报表
架构核心优势：一份原始数据，两套存储引擎。TiKV行存保障毫秒级交易写入，TiFlash列存支撑海量秒级聚合，读写、分析资源完全隔离，互不干扰。
四、零停机迁移方案：4个阶段完美落地（可直接复用）
本次迁移全程无业务停机、无数据丢失、产线不间断上报，整套流程分为兼容性整改、全量导入、增量同步、灰度切换四个阶段，是制造业MES迁移最稳妥的方案。
阶段1：迁移前兼容性全面排查整改
通过TiDB官方sync-check工具扫描全部48张分片表，统一整改三类不兼容问题：
• 废弃复杂存储过程，将业务逻辑全部下沉至应用层，规避兼容性问题
• 重构主键规则：删除分片自增ID，替换为AUTO_RANDOM，彻底解决写入热点
• 淘汰分区表、ENUM字段，ENUM统一转为VARCHAR，规避同步报错
• 所有核心业务表强制设置唯一主键，杜绝依赖隐式_rowid
阶段2：凌晨低峰全量合并导入，48分表合并为单逻辑表
利用凌晨产线低峰窗口完成历史数据迁移，全程业务无感知：
1. 通过Dumpling工具并行导出48张分片数据，按工厂编号设置偏移量，杜绝主键冲突
2. 使用Lightning高速导入，将48张子表直接合并为一张逻辑大表
3. 1.8TB全量数据，耗时10小时完成导入，全程零业务中断
阶段3：DM集群增量实时同步，保障双库数据一致
全量数据对齐后，搭建DM同步集群实时解析MySQL Binlog，跟进增量数据。
初期同步延迟20秒，优化TiKV队列、批量写入参数后，稳定延迟控制在300ms以内，完全满足产线秒级数据上报需求。同时配置自动校验脚本，每日凌晨全量对比双库数据，确保零差异。
阶段4：四级灰度切换，风险可控、支持快速回滚
为最大限度规避上线风险，我们采用阶梯式灰度，每阶段稳定24小时无异常再推进下一步：
1. 只读灰度：10%→50%→100% 逐步将报表、大屏查询切换至TiDB，监控延迟、CPU、内存指标
2. 双写并行：双库同时写入，自动校验数据一致性，异常立即回滚MySQL
3. 业务灰度：先切二线车间流量，稳定后再切换核心自动化产线
4. 全量上线：连续7天零数据异常、性能达标后，下线原有MySQL分片集群
整个业务改造仅修改JDBC连接地址、新增批量写入参数，仅数百行代码改动，无需重构分片逻辑，研发成本极低。
五、硬核性能对比：迁移前后差距一目了然
集群稳定运行一个月后，我们采集生产高峰、月度报表两大核心场景真实数据，性能提升极其显著。
1. OLTP交易性能（产线写入）
• 工单提交TP99延迟：260ms → 62ms，下降76%
• 峰值TPS承载：1.8万 → 3.2万，彻底告别高峰期限流
• DDL变更：3小时停机操作 → 在线秒级变更，无需停机窗口
2. OLAP分析性能（生产报表）
• 原MySQL跨分片报表：40分钟+，仅支持T+1离线统计
• TiDB+TiFlash同款SQL：平均0.8秒返回
项目完成后直接下线ClickHouse集群，一套集群搞定交易+分析，彻底消除双集群运维成本。
3. 运维与存储成本
• 磁盘占用：1.8TB → 1.1TB，存储空间节省38%
• 运维工时：每周2天分片运维 → 每周2小时常规巡检
六、上线真实踩坑汇总（制造业MES必看避坑指南）
整理项目落地中6个高频问题及最终解决方案，同行可直接提前规避：
1. 自增主键导致写入热点
初期沿用MySQL自增ID，同车间工单集中写入单个Region，TiKV单节点CPU打满、数据上报卡顿。解决方案：主键改为AUTO_RANDOM，数据自动打散全节点，压力均匀分布。
2. 未开启批量参数，工序入库效率极低
MES批量上报数据无批量写入配置，单次千条插入缓慢堆积。解决方案：开启rewriteBatchedStatements参数，批量写入性能提升6倍。
3. 全量表默认开启TiFlash，磁盘资源浪费
流水、日志类低查询量表开启列存副本，占用大量存储空间。解决方案：仅为统计、报表核心表开启TiFlash，流水日志表关闭列存。
4. MySQL大DDL导致DM同步中断
源库变更表结构，同步链路直接报错中断。解决方案：先在TiDB预执行DDL，验证兼容后再操作MySQL源库。
5. 超大聚合查询触发内存超限
数十亿行数据统计超出单查询内存限制。解决方案：调高tidb_mem_quota参数，为报表SQL配置专属TiFlash执行计划。
6. 多分片导入主键冲突
历史48张子表存在ID重复，导致导入失败。解决方案：导出阶段按分片设置ID偏移量，从源头规避冲突。
七、项目最终收益：架构升级赋能生产数字化
1. 研发迭代效率翻倍
彻底告别分片规则设计与维护，新增分厂、新增产线无需改动数据库代码，业务需求迭代周期直接缩短50%。
2. 运维压力大幅减负
48张分片表的复杂运维，简化为单逻辑表常规巡检，下线ClickHouse集群，DBA精力从重复运维转向架构优化、性能调优。
3. 整体硬件TCO下降35%
精简服务器数量，依托TiDB数据压缩能力节省大量存储，硬件采购、电费、维保成本全面降低。
4. 工厂精细化管理落地
实现生产数据当日实时分析，智能排产、物料动态调配、设备故障预警全部落地，彻底告别滞后的T+1数据决策。
八、核心总结
MySQL分库分表，从来都不是制造业数字化的终极方案，只是数据体量小时的临时兜底手段。
一旦工厂扩建、产线自动化升级、数据量级突破十亿级，分片架构的扩容难、统计慢、运维重、迭代慢的问题会持续放大，严重制约业务发展。
对于MES、ERP等制造核心系统，TiDB 8.0 HTAP分布式架构是现阶段最优解：一套集群兼顾高并发交易与海量实时分析，原生分布式免分片、兼容MySQL改造成本低、高可用保障生产稳定。
技术选型从不追新，贴合业务真实增长、解决核心痛点、长期降本增效，才是最好的架构。