很多公司都禁止程序员在 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 的使用，那么不妨把本文的链接发给他，因为他多半没有搞清楚真正的原因是什么。
觉得文章有用？立即：
和朋友一起 共学习 共进步！
新年快乐
JOIN 后效率奇差的例子，不过这样的问题一来可能是索引不佳，二来可能是特殊情况，用不用 JOIN 都会有类似的问题，只要使用的时候留意即可。
哎，这废物真是把家族的脸都给丢光了。”
“要不是族长是他的父亲，这种废物，早就被驱赶出家族，任其自生自灭了，哪还有机会待在家族中白吃白喝。”
“唉，昔年那名闻乌坦城的天才少年，如今怎么落魄成这般模样了啊？”
“谁知道呢，或许做了什么亏心事，惹得神灵降怒了吧…”
周围传来的不屑嘲笑以及惋惜轻叹，落在那如木桩待在原地的少年耳中，恍如一根根利刺狠狠的扎在心脏一般，让得少年呼吸微微急促。
大神，如上述的两个数据表：帖子表和用户表。如果需要用户表其中某一列作为筛选条件的话，并且用户表出来的结果会很大，然后分页展示这些人的帖子。还是建议程序组装吗？该如何组装？还是不建议拆分库的时候不拆分？请大神指教