mysql的join查询和多次查询方式比较

目录

• join查询和多次查询比较
• 查询语句join、on、where执行顺序
• 一、典型SELECT语句完整的执行顺序
• 二、from
• 三、on
• 四、on 条件与where 条件
• 五、join 流程
• 总结

join查询和多次查询比较

mysql多表关联查询效率高点还是多次单表查询效率高？

在数据量不够大的时候，用join没有问题，但是一般都会拉到service层上去做

第一：单机数据库计算资源很贵，数据库同时要服务写和读，都需要消耗CPU，为了能让数据库的吞吐变得更高，而业务又不在乎那几百微妙到毫秒级的延时差距，业务会把更多计算放到service层做，毕竟计算资源很好水平扩展，数据库很难啊，所以大多数业务会把纯计算操作放到service层做，而将数据库当成一种带事务能力的kv系统来使用，这是一种重业务，轻DB的架构思路

第二：很多复杂的业务可能会由于发展的历史原因，一般不会只用一种数据库，一般会在多个数据库上加一层中间件，多个数据库之间就没办法join了，自然业务会抽象出一个service层，降低对数据库的耦合。

第三：对于一些大型公司由于数据规模庞大，不得不对数据库进行分库分表，对于分库分表的应用，使用join也受到了很多限制，除非业务能够很好的根据sharding key明确要join的两个表在同一个物理库中。而中间件一般对跨库join都支持不好。

举一个很常见的业务例子，在分库分表中，要同步更新两个表，这两个表位于不同的物理库中，为了保证数据一致性，一种做法是通过分布式事务中间件将两个更新操作放到一个事务中，但这样的操作一般要加全局锁，性能很捉急，而有些业务能够容忍短暂的数据不一致，怎么做？让它们分别更新呗，但是会存在数据写失败的问题，那就起个定时任务，扫描下A表有没有失败的行，然后看看B表是不是也没写成功，然后对这两条关联记录做订正，这个时候同样没法用join去实现，只能将数据拉到service层应用自己来合并了。。。

事实上，用分解关联查询的方式重构查询具有如下优势：

让缓存的效率更高。

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

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

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

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

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

更进一步，这样做相当于在应用中实现了哈希关联，而不是使用MySQL的嵌套环关联，某些场景哈希关联的效率更高很多。

查询语句join、on、where执行顺序

MySQL 的执行顺序

一、典型SELECT语句完整的执行顺序

1）from子句组装来自不同数据源的数据；

2）使用on进行join连接的数据筛选

3）where子句基于指定的条件对记录行进行筛选；

4）group by子句将数据划分为多个分组；

5）cube， rollup

6）使用聚集函数进行计算；

7）使用having子句筛选分组；

8）计算所有的表达式；

9）计算select的字段；

10）使用distinct 进行数据去重

11）使用order by对结果集进行排序。

12）选择TOPN的数据

二、from

如果是采用的 关联 from tableA, tableB ，这2个表会先组织进行笛卡尔积，然后在进行下面的 whjavascriptere、group by 等操作。

三、on

如果使用left join， inner join 或者 outer full join的时候，使用on 进行条件筛选后，在进行join。

看下面的2js个sql 和结果。2者的区别仅仅是在on后面的一个语句在on和where位置的不同。 由此可以看出是先通过on 进行条件筛选，然后在join，最后在进行where条件筛选。

假如：是先进行join，在进行on的话，会产生一个笛卡尔积，然后在筛选。这样的left join 和 直连接 没有任何的区别。 所以肯定是先on 条件筛选后，在进行join。

假如：是在进行where 后，在on，在进行join， 下面2个sql的返回结果应该是一样的。由此可以见，where是针对 join 后的集合进行的筛选。

综上： 先 执行on 条件筛选， 在进行join， 最后进行where 筛选开发者_SQLite

SELECT DISTINCT a.domain , b.domain
FROM mal_nxdomains_raw a
LEFT JOIN mal_nxdomains_javascriptdetail b ON a.domain = b.domain AND b.date = ‘20160403'
WHERE a.date = ‘20160403'

SELECT DISTINCT a.domain , b.domain
FROM mal_nxdomains_raw a
LEFT JOIN mal_nxdomains_detail b ON a.domain = b.domain #and b.date = ‘20160403'
WHERE a.date = ‘20160403'
AND b.date = ‘20160403'

四、on 条件与where 条件

1、使用位置

• on 条件位置在join后面
• where 条件在join 与on完成的后面

2、使用对象

• on 的使用对象是被关联表
• where的使用对象可以是主表，也可以是关联表

3、选择与使用

主表条件筛选：只能在where后面使用。

被关联表，如果是想缩小join范围，可以放置到on后面。如果是关联后再查询，可以放置到where 后面。

如果left join 中，where条件有对被关联表的 关联字段的 非空查询，与使用inner join的效果后，在进行where 筛选的效果是一样的。不能起到left join的作用。

五、join 流程

tableA join tableB， 从A表中拿出一条数据，到B表中进行php扫描匹配。所以A的行数决定查询次数，B表的行数决定扫描范围。例如A表100条，B表200表，需要100次从A表中取出一条数据到B表中进行200次的比对。

相对来说从A表取数据消耗的资源比较多。所以尽量tableA选择比较小的表。同时缩小B表的查询范围。

但是实际应用中，因为二者返回的数据结果不同，使用的索引也不同，导致条件放置在on 和 where 效率是不一定谁更好android。要根据需求来确定。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。