将主键为customer_id的大表拆分为8000个客户单表是否可行？

我在生产环境碰过类似的单租户分表需求，直接拆成数千张单客户表的问题远多于收益，绝对不建议你这么干，以下是实际踩过的坑和更合理的替代方案：

直接拆表的核心痛点 #

• 运维成本直线飙升：备份恢复要处理8000张表，要么写复杂脚本循环导出单表，要么全库导出（体积巨大）；某客户数据出问题时，得从海量表文件里定位对应的表，排查效率极低。日常监控性能、慢查询分析都得针对每张表做适配，运维复杂度呈指数级增长。
• 应用层改造风险大：原来的SQL只需要带customer_id过滤，现在得动态拼接表名（比如order_123），不管是ORM还是原生SQL都要加路由逻辑，很容易出现表名拼写错误、客户ID映射偏差等问题，上线后这类问题排查耗时极久。
• 性能反而下降：MySQL的table_open_cache有上限，8000张表会导致大量冷表被频繁换出缓存，每次访问冷表都得重新打开表文件，IO开销远大于customer_id索引的维护开销，实际查询速度反而不如原单表带索引的情况。
• 扩展性极差：如果后续客户数涨到1万、2万，你总不能继续新增表吧？随着表数量增加，MySQL的元数据管理会出现隐性性能损耗，到时候再想回头合并表，成本高到离谱。

更稳妥的替代方案 #

• 哈希分区表：以customer_id为键做哈希分区，分成32或64个分区（不用和客户数一一对应），MySQL会自动路由查询到对应分区，应用层无需修改任何SQL，运维还是单表模式，备份恢复、监控都和原来一致，查询效率和单客户表接近，还能利用分区修剪快速过滤数据。
• 原表优化+归档：百万行的表其实不算大，只要customer_id是主键，主键查询的性能完全够用。可以定期将历史数据（比如超过1年的）归档到单独的历史表，主表只保留近期数据，进一步提升查询速度；也可以给customer_id配合适的二级索引，优化查询路径。

我之前有个项目一时脑热拆了2000多张单客户表，后来运维和应用层问题不断，花了3个月才合并回分区表。你当前的场景，拆8000张表绝对是得不偿失的选择，优先考虑分区表或者原表优化的方案，成本低、风险小，生产环境更稳定。

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