这是个非常典型的多租户数据存储设计抉择问题，我结合实际项目经验给你拆解下两种方案的优劣和真实性能差异：

• 维护成本爆炸：先不说性能，光是维护就能让你头大——要是有1000个客户，那就是1000×10=10000张表！写SQL得动态拼接表名，备份、加字段、改索引都得批量操作，万一某个客户的表结构出了问题（比如之前的脚本没执行成功），排查起来能把人逼疯。
• 数据库资源浪费：MySQL的每张表都会占用元数据缓存（比如表结构、索引信息），表太多会吃掉大量内存，反而挤占业务数据的缓存空间，导致查询变慢。而且如果大部分客户数据量很小（比如只有几千行），单独建表会造成严重的磁盘碎片化，IO效率大幅降低。
• 性能瓶颈没真正解决：你以为分表能提升性能，但如果某个客户的数据量特别大（比如单客户就有100万行），他的10张表照样会遇到单表的性能问题，到时你还得再拆分这个客户的表，复杂度直接翻倍。另外，跨客户的统计查询（比如所有客户的总销售额）会变得无比麻烦，得用UNION ALL拼接所有表，性能极差。

• 维护简单到飞起：一张（或10张通用）表，结构统一，加字段、改索引、备份都只需要操作一次。开发时不用动态拼表名，代码逻辑更简洁，不容易出bug。
• 性能完全可控：100万行的单表在MySQL里根本不是事儿，只要索引设计合理，查询速度会非常快。比如给customer_id加个联合索引（比如(customer_id, created_at)），查询某个客户的数据时，MySQL能快速定位到对应行，效率拉满。而且MySQL的查询优化器对单表的优化更成熟，执行计划更稳定。
• 扩展性更强：如果以后数据量涨到几千万甚至几亿行，你可以再考虑按customer_id哈希分表（比如分成10或20张表），这种分表是有规律的，维护成本比按客户单独建表低太多。

• 单客户查询：如果客户数据量小，两种方案差异不大；但如果客户数据量大，单表加合适索引的查询速度，不会比单独建表慢，甚至可能更快——因为MySQL的缓存机制对单表的缓存效率更高。
• 批量/统计查询：单表优势碾压，跨客户统计直接用GROUP BY就能搞定；而按客户分表需要UNION ALL所有相关表，不仅代码复杂，性能也差很多，客户数量越多越明显。
• 运维性能：单表的备份、恢复、优化（比如OPTIMIZE TABLE）都比几千张表快得多，运维成本低很多，间接提升了系统稳定性。

除非你的业务有非常特殊的需求（比如每个客户的数据必须物理隔离，合规要求不能和其他客户数据存同一张表），否则优先选择单表（或通用的几张表）存储所有客户数据，并做好以下几点：

• 每张表必须加customer_id字段，作为核心过滤条件，建立联合索引（比如(customer_id, created_at)），确保单客户查询的效率。
• 定期清理过期数据，如果数据增长快，考虑用分区表（比如按时间分区），进一步提升查询和维护效率。
• 监控单表行数和索引情况，当单表行数超过5000万（可根据你的硬件配置调整）时，再考虑按customer_id哈希分表，这种分表是可控的。

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