join查詢和多次查詢比較

MySQL多表關(guān)聯(lián)查詢效率高點還是多次單表查詢效率高？

在數(shù)據(jù)量不夠大的時候，用join沒有問題，但是一般都會拉到service層上去做

第一：單機數(shù)據(jù)庫計算資源很貴，數(shù)據(jù)庫同時要服務寫和讀，都需要消耗CPU，為了能讓數(shù)據(jù)庫的吞吐變得更高，而業(yè)務又不在乎那幾百微妙到毫秒級的延時差距，業(yè)務會把更多計算放到service層做，畢竟計算資源很好水平擴展，數(shù)據(jù)庫很難啊，所以大多數(shù)業(yè)務會把純計算操作放到service層做，而將數(shù)據(jù)庫當成一種帶事務能力的kv系統(tǒng)來使用，這是一種重業(yè)務，輕DB的架構(gòu)思路

第二：很多復雜的業(yè)務可能會由于發(fā)展的歷史原因，一般不會只用一種數(shù)據(jù)庫，一般會在多個數(shù)據(jù)庫上加一層中間件，多個數(shù)據(jù)庫之間就沒辦法join了，自然業(yè)務會抽象出一個service層，降低對數(shù)據(jù)庫的耦合。

第三：對于一些大型公司由于數(shù)據(jù)規(guī)模龐大，不得不對數(shù)據(jù)庫進行分庫分表，對于分庫分表的應用，使用join也受到了很多限制，除非業(yè)務能夠很好的根據(jù)sharding key明確要join的兩個表在同一個物理庫中。而中間件一般對跨庫join都支持不好。

舉一個很常見的業(yè)務例子，在分庫分表中，要同步更新兩個表，這兩個表位于不同的物理庫中，為了保證數(shù)據(jù)一致性，一種做法是通過分布式事務中間件將兩個更新操作放到一個事務中，但這樣的操作一般要加全局鎖，性能很捉急，而有些業(yè)務能夠容忍短暫的數(shù)據(jù)不一致，怎么做？讓它們分別更新唄，但是會存在數(shù)據(jù)寫失敗的問題，那就起個定時任務，掃描下A表有沒有失敗的行，然后看看B表是不是也沒寫成功，然后對這兩條關(guān)聯(lián)記錄做訂正，這個時候同樣沒法用join去實現(xiàn)，只能將數(shù)據(jù)拉到service層應用自己來合并了。。。

事實上，用分解關(guān)聯(lián)查詢的方式重構(gòu)查詢具有如下優(yōu)勢：

讓緩存的效率更高。

許多應用程序可以方便地緩存單表查詢對應的結(jié)果對象。另外對于MySQL的查詢緩存來說，如果關(guān)聯(lián)中的某個表發(fā)生了變化，那么就無法使用查詢緩存了，而拆分后，如果某個表很少改變，那么基于該表的查詢就可以重復利用查詢緩存結(jié)果了。

將查詢分解后，執(zhí)行單個查詢可以減少鎖的競爭。

在應用層做關(guān)聯(lián)，可以更容易對數(shù)據(jù)庫進行拆分，更容易做到高性能和可擴展。

查詢本身效率也可能會有所提升

可以減少冗余記錄的查詢。

更進一步，這樣做相當于在應用中實現(xiàn)了哈希關(guān)聯(lián)，而不是使用MySQL的嵌套環(huán)關(guān)聯(lián)，某些場景哈希關(guān)聯(lián)的效率更高很多。

查詢語句join、on、where執(zhí)行順序

MySQL 的執(zhí)行順序

一、典型SELECT語句完整的執(zhí)行順序

1）from子句組裝來自不同數(shù)據(jù)源的數(shù)據(jù)；

2）使用on進行join連接的數(shù)據(jù)篩選

3）where子句基于指定的條件對記錄行進行篩選；

4）group by子句將數(shù)據(jù)劃分為多個分組；

5）cube， rollup

6）使用聚集函數(shù)進行計算；

7）使用having子句篩選分組；

8）計算所有的表達式；

9）計算select的字段；

10）使用distinct 進行數(shù)據(jù)去重

11）使用order by對結(jié)果集進行排序。

12）選擇TOPN的數(shù)據(jù)

二、from

如果是采用的 關(guān)聯(lián) from tableA, tableB ，這2個表會先組織進行笛卡爾積，然后在進行下面的 where、group by 等操作。

三、on

如果使用left join， inner join 或者 outer full join的時候，使用on 進行條件篩選后，在進行join。

看下面的2個sql 和結(jié)果。2者的區(qū)別僅僅是在on后面的一個語句在on和where位置的不同。 由此可以看出是先通過on 進行條件篩選，然后在join，最后在進行where條件篩選。

假如：是先進行join，在進行on的話，會產(chǎn)生一個笛卡爾積，然后在篩選。這樣的left join 和 直連接 沒有任何的區(qū)別。 所以肯定是先on 條件篩選后，在進行join。

假如：是在進行where 后，在on，在進行join， 下面2個sql的返回結(jié)果應該是一樣的。由此可以見，where是針對 join 后的集合進行的篩選。

綜上： 先 執(zhí)行on 條件篩選， 在進行join， 最后進行where 篩選

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'

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 的使用對象是被關(guān)聯(lián)表
• where的使用對象可以是主表，也可以是關(guān)聯(lián)表

3、選擇與使用

主表條件篩選：只能在where后面使用。

被關(guān)聯(lián)表，如果是想縮小join范圍，可以放置到on后面。如果是關(guān)聯(lián)后再查詢，可以放置到where 后面。

如果left join 中，where條件有對被關(guān)聯(lián)表的 關(guān)聯(lián)字段的 非空查詢，與使用inner join的效果后，在進行where 篩選的效果是一樣的。不能起到left join的作用。

五、join 流程

tableA join tableB， 從A表中拿出一條數(shù)據(jù)，到B表中進行掃描匹配。所以A的行數(shù)決定查詢次數(shù)，B表的行數(shù)決定掃描范圍。例如A表100條，B表200表，需要100次從A表中取出一條數(shù)據(jù)到B表中進行200次的比對。

相對來說從A表取數(shù)據(jù)消耗的資源比較多。所以盡量tableA選擇比較小的表。同時縮小B表的查詢范圍。

但是實際應用中，因為二者返回的數(shù)據(jù)結(jié)果不同，使用的索引也不同，導致條件放置在on 和 where 效率是不一定誰更好。要根據(jù)需求來確定。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論