一.Join执行过程
SELECT <row_list>
FROM <left_table>
<inner|left|right> JOIN <right_table>
ON <join condition>
WHERE <where_condition>
它的执行顺序如下(SQL语句里第一个被执行的总是FROM子句):
- FROM:对左右两张表执行笛卡尔积,产生第一张表vt1。行数为n*m(n为左表的行数,m为右表的行数
- ON:根据ON的条件逐行筛选vt1,将结果插入vt2中
- JOIN:添加外部行,如果指定了LEFT JOIN(LEFT OUTER JOIN),则先遍历一遍左表的每一行,其中不在vt2的行会被插入到vt2,该行的剩余字段将被填充为NULL,形成vt3;如果指定了RIGHT JOIN也是同理。但如果指定的是INNER JOIN,则不会添加外部行,上述插入过程被忽略,vt2=vt3(所以INNER JOIN的过滤条件放在ON或WHERE里 执行结果是没有区别的,下文会细说)
- WHERE:对vt3进行条件过滤,满足条件的行被输出到vt4
- SELECT:取出vt4的指定字段到vt5
摘抄自:https://segmentfault.com/a/1190000015572505
二.性能对比
1.使用Join:
过程:(产生笛卡尔成绩==》on过滤==》添加外部行 ) *2次 ==》where过滤 ==》select显示
select * from tag
join tag_post on tag_post.tag_id = tag.id
join post on tag_post.post_id = post.id
where tag.tag=’mysql’;
2.不使用join:
过程:(where过滤 ==》网络返回给应用处理 ) *3次
Select * from tag where tag=’mysql’;
Select * from tag_post where tag_id=1234;
Select * from post where id in(123,456,567,9989,8909);
从上执行步骤对比:一个偏向于数据库内部运算,一个偏向于应用程处理,需要多走几次网络
分解关联查询的方式重构查询具有如下优势:
- 让缓存的效率更高。
许多应用程序可以方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来说,如果关联中的某个表发生了变化,那么就无法使用查询缓存了,而拆分后,如果某个表很少改变,那么基于该表的查询就可以重复利用查询缓存结果了。
-
将查询分解后,执行单个查询可以减少锁的竞争。
-
在应用层做关联,可以更容易对数据库进行拆分,更容易做到高性能和可扩展。
-
查询本身效率也可能会有所提升
-
可以减少冗余记录的查询。
-
更进一步,这样做相当于在应用中实现了哈希关联,而不是使用MySQL的嵌套环关联,某些场景哈希关联的效率更高很多。
通过查询资料及及个人理解:
在数据量小,关联表少的情况下,可以使用join关联查询
但是在大数据量或多个表的情况下最好不要使用,因为一个语句关联多个表的话,会涉及到笛卡尔乘机,表锁,此时对业务复杂场景,比如数据库分库分表场景,分布式等。
结合本人另一篇:为什么不推荐使用外键
从join及外键的使用上个人总结:
无论从建表结构还是sql查询上,尽量减少表之间的关联性操作,让操作单表化,数据之间的联合处理放在代码里面处理。
本分参考:
https://blog.csdn.net/fzy629442466/article/details/90711021
https://www.zhihu.com/question/68258877
https://www.zhihu.com/question/56236190
https://segmentfault.com/a/1190000015572505