MySQL快速增长的EntityMapping表拆分可行性及方案价值咨询

分表是当前阶段的必要最佳实践 #

你的EntityMapping表已经140亿行，6个月后将增长至300亿行，单表绝对无法支撑——MySQL单表数据量超过10亿行后，哪怕索引配置完善，查询延迟、磁盘IO压力、备份/表优化等维护成本都会呈指数级上升。当前750GB的表未来翻倍到1.5TB后，单表的DDL操作（比如加字段、调整索引）基本会锁表数小时，完全无法适配在线业务需求。你想保留单表简化UNION操作的想法可以理解，但性能与可维护性的优先级远高于操作简化，单表在这个数据量级下没有长期生存空间。

基于entityTableMapping元表的分表方案可行，且能控制代码修改成本 #

你计划用元表通过entityId定位分表的思路，本质是基于entityId的水平分片路由，非常贴合你的业务场景（每个实体关联百万级数据），属于合理的分片策略。针对代码修改成本的担忧，可以通过以下方式规避：

• 封装路由逻辑到数据访问层（DAO）：无需全量修改业务代码，只需要在DAO层统一实现路由逻辑——比如用MyBatis的动态表名插件，或者自定义DAO方法，先查询元表拿到对应分表名，再动态拼接SQL执行。上层业务代码依旧调用原查询接口，完全感知不到分表的存在。
• 缓存路由规则：把entityId与分表名的映射关系缓存到Redis等内存缓存中，减少对元表的高频查询，同时提升路由效率。

该方案的长期价值明确 #

这个分片方案的扩展性与可维护性优势会随着数据增长逐渐凸显：

• 动态扩容：未来数据持续增长时，只需新增分片表、更新元表的路由规则即可，无需重构整个数据结构；
• 可控的维护成本：每个分片表的数据量可控制在几亿行级别（比如按entityId范围或哈希分片，每个分片对应若干实体），备份、优化、故障恢复的成本都会大幅降低；
• 针对性优化：可对不同分片做个性化配置（比如热门实体的分片单独搭配更高性能的存储），提升核心业务的响应速度。

额外注意事项 #

• 分片规则提前规划：优先保证高频查询（比如按entityId查询）不跨分片，避免跨分片的大查询；如果有按contactId或Added time的跨分片需求，建议通过数据同步到数据仓库做离线分析，在线业务尽量规避这类操作。
• 元表高可用保障：元表本身数据量极小，需配置主从复制或双活模式，避免成为单点故障；路由逻辑中要加入降级处理，比如缓存失效时直接查询元表，保证服务可用性。
• 在线数据迁移：现有140亿行数据迁移到分表时，必须采用在线迁移方案（比如自定义分批迁移程序，或使用pt-online-schema-change这类工具），避免停机影响业务，同时做好数据一致性校验。

内容的提问来源于stack exchange，提问作者Arunkumar Muthuvel