SQL里是否可以使用JOIN

   很多公司都禁止程序员在 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

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

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

觉得文章有用?立即: 和朋友一起 共学习 共进步!

猜您喜欢

4 thoughts on “SQL里是否可以使用JOIN

  1. 哎,这废物真是把家族的脸都给丢光了。”

    “要不是族长是他的父亲,这种废物,早就被驱赶出家族,任其自生自灭了,哪还有机会待在家族中白吃白喝。”

    “唉,昔年那名闻乌坦城的天才少年,如今怎么落魄成这般模样了啊?”

    “谁知道呢,或许做了什么亏心事,惹得神灵降怒了吧…”

    周围传来的不屑嘲笑以及惋惜轻叹,落在那如木桩待在原地的少年耳中,恍如一根根利刺狠狠的扎在心脏一般,让得少年呼吸微微急促。

  2. 大神,如上述的两个数据表:帖子表和用户表。如果需要用户表其中某一列作为筛选条件的话,并且用户表出来的结果会很大,然后分页展示这些人的帖子。还是建议程序组装吗?该如何组装?还是不建议拆分库的时候不拆分?请大神指教

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>