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

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

SELECT posts.id, posts.content, users.name, ...
FROM posts
JOIN users on posts.user_id = users.id
ORDER BY posts.created_at DESC
LIMIT 10

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

SELECT id, content, ...
FROM posts
ORDER BY created_at DESC
LIMIT 10

SELECT name, ...
FROM users
WHERE id in (...)

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

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

JOIN

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

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

建议继续学习：

1. HBase二级索引与Join    (阅读：5618)
2. Oracle hash join    (阅读：3061)
3. MySQL 连接    (阅读：2949)
4. 一个有趣的SQL查询    (阅读：2696)
5. MySQL源代码的海洋中游弋 初探MySQL之SQL执行过程    (阅读：2632)
6. MySQL MongoDB SQL 对应    (阅读：2422)
7. MySQL数据库InnoDB存储引擎查询优化器实现的分析之多表简单JOIN查询    (阅读：1845)
8. SQL 新手指南    (阅读：1851)