很多公司都禁止程序员在 SQL 中使用 JOIN，至于起因则出奇的一致：用 JOIN 慢。不过我从没见过谁来论证为什么用 JOIN 慢，结果这个人云亦云的结论越传越广，让我觉得是时候来探讨一下这个看似正确的结论了。

举个例子：查询最新的十篇帖子和对应的客户信息，用 JOIN 是这样的：

假如不使用 JOIN 的话，那么大概会改写成如下两条 SQL：

第一次查询得到帖子数据，而后在程序代码里收集好想要的 user_id，第二次查询通过 user_id 得到客户数据，接着在程序代码里把两份数据组合起来。

哪个快？我就不用跑个 bench 了吧，正常人都能看出来是用 JOIN 的快！

在我看来，JOIN 的问题不是性能，而是当你执行 posts JOIN users 的时候，实际上相当于做出了一个承诺：posts 和 users 两个结婚的表将永远住在同一个 DB 实例上，以后无论贫穷还是富有，疾病还是健康，永不分离。不过实际上，随着项目的发展，很可能会出现 posts 和 users 两个表不得不离婚的情况，结果它们会被划分到不同 DB 实例，一旦出现此类情况，那么当初使用 JOIN 的地方将不得不大量改写。

至于 SQL 里能否可以使用 JOIN，假如相关的表以后有独立部署的可能性，那么就要考虑避免使用 JOIN，否则用 JOIN 也无妨。当然，有人会找出少量使用 JOIN 后效率奇差的例子，不过这样的问题一来可能是索引不佳，二来可能是特殊情况，用不用 JOIN 都会有相似的问题，只需使用的时候留意就可。下次假如大家再听到别人以性能为由反对 JOIN 的使用，那么不妨把本文的链接发给他，由于他多半没有搞清楚真正的起因是什么。