用分表/数组实现数据库一对多关系是否比传统JOIN性能更优？

先纠正一个前提错误 #

你认为常规方案需要遍历整个Tracks表筛选数据，这个认知是完全错误的。只要你给Tracks表的album_id字段加普通索引，查询某张专辑下的曲目时，数据库会直接通过索引定位到所有匹配的行，根本不会扫描全表，过滤开销可以忽略不计。

分表设计的性能对比结论 #

绝大多数场景下，这个设计的性能不会比常规加索引的方案更好，甚至会更差，理由如下：

• 你需要两次数据库请求才能拿到结果：第一次查Albums表获取表名，第二次动态拼接SQL查询对应分表，多了一次数据库交互开销，而常规方案单条SELECT * FROM Tracks WHERE album_id = ?就能拿到结果。
• 分表会大幅降低数据库缓存命中率：常规单表方案的Tracks表数据和索引都会被数据库缓存，而大量小分表会分散缓存资源，缓存失效概率更高，冷查询时的IO开销反而更大。
• 就算是需要关联查询专辑和曲目信息的场景，加了索引的JOIN性能也远高于你的分表方案：JOIN是数据库内核层面优化过的操作，开销远低于两次独立查询加业务层的逻辑拼接。

这个设计的其他致命问题 #

就算你完全不在乎反向查询的需求，这个设计的维护成本也高到几乎不可用：

• 新增专辑就要动态建表、删除专辑就要删表，专辑量大的情况下会产生成千上万张小表，数据库的元数据管理压力会剧增，备份、迁移、表结构变更（比如要给曲目加个「时长」字段）都需要操作所有分表，工作量极大。
• 动态表名的SQL无法使用预编译，不仅有SQL注入的风险，也无法利用数据库的预编译语句缓存，进一步降低性能。

替代方案 #

如果你确实有单专辑曲目量极大、查询热点集中的场景，应该用数据库自带的分区表功能，按照album_id对Tracks表做分区，数据库底层会自动把不同专辑的数据存在不同的物理块上，查询时自动定位到对应分区，性能和你手动分表一致，但对业务层完全透明，不需要维护大量表名。

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