sql中的join(2)：join执行过程，性能分析，使用join好还是单独查几个表好？

一.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);

从上执行步骤对比：一个偏向于数据库内部运算，一个偏向于应用程处理，需要多走几次网络

分解关联查询的方式重构查询具有如下优势：

1. 让缓存的效率更高。

许多应用程序可以方便地缓存单表查询对应的结果对象。另外对于MySQL的查询缓存来说，如果关联中的某个表发生了变化，那么就无法使用查询缓存了，而拆分后，如果某个表很少改变，那么基于该表的查询就可以重复利用查询缓存结果了。

1. 将查询分解后，执行单个查询可以减少锁的竞争。

2. 在应用层做关联，可以更容易对数据库进行拆分，更容易做到高性能和可扩展。

3. 查询本身效率也可能会有所提升

4. 可以减少冗余记录的查询。

5. 更进一步，这样做相当于在应用中实现了哈希关联，而不是使用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