為什麼MySQL不推薦使用子查詢和join

2021-08-22 11:51:08 字數 1119 閱讀 8271

前言:

1.對於mysql,不推薦使用子查詢和join是因為本身join的效率就是硬傷,一旦資料量很大效率就很難保證,強烈推薦分別根據索引單錶取資料,然後在程式裡面做join,merge資料。

2.子查詢就更別用了,效率太差,執行子查詢時,mysql需要建立臨時表,查詢完畢後再刪除這些臨時表,所以,子查詢的速度會受到一定的影響,這裡多了乙個建立和銷毀臨時表的過程。

3.如果是join的話,它是走巢狀查詢的。小表驅動大表,且通過索引字段進行關聯。如果表記錄比較少的話,還是ok的。大的話業務邏輯中可以控制處理。

4.資料庫是最底層的,瓶頸往往是資料庫。建議資料庫只是作為資料store的工具,而不要新增業務上去。

一、應用層關聯的優勢:

二、應用層關聯的使用場景:

1.db承擔的業務壓力大,能減少負擔就減少。當表處於百萬級別後,join導致效能下降; 

2.分布式的分庫分表。這種時候是不建議跨庫join的。目前mysql的分布式中介軟體,跨庫join表現不良。 

3.修改表的schema,單錶查詢的修改比較容易,join寫的sql語句要修改,不容易發現,成本比較大,當系統比較大時,不好維護。

四、不使用join的解決方法:

在業務層,單錶查詢出資料後,作為條件給下乙個單錶查詢。也就是子查詢。 會擔心子查詢出來的結果集太多。mysql對in的數量沒有限制,但是mysql限制整條sql語句的大小。通過調整引數max_allowed_packet ,可以修改一條sql的最大值。建議在業務上做好處理,限制一次查詢出來的結果集是能接受的。

五、再來說說join查詢的好處:

1.做分頁查詢:

關聯查詢的好處時候可以做分頁,可以用副表的字段做查詢條件,在查詢的時候,將副表匹配到的字段作為結果集,用主表去in它,但是問題來了,如果匹配到的資料量太大就不行了,也會導致返回的分頁記錄跟實際的不一樣,解決的方法可以交給前端,一次性查詢,讓前端分批顯示就可以了,這種解決方案的前提是資料量不太,因為sql本身長度有限。

為什麼MySQL不推薦使用子查詢和join

前言 1.對於mysql,不推薦使用子查詢和join是因為本身join的效率就是硬傷,一旦資料量很大效率就很難保證,強烈推薦分別根據索引單錶取資料,然後在程式裡面做join,merge資料。2.子查詢就更別用了,效率太差,執行子查詢時,mysql需要建立臨時表,查詢完畢後再刪除這些臨時表,所以,子查...

mysql為什麼不推薦使用uuid作為主鍵

前言 在mysql中設計表的時候,mysql官方推薦不要使用uuid或者不連續不重複的雪花id long形且唯一 而是推薦連續自增的主鍵id,官方的推薦是auto increment,那麼為什麼不建議採用uuid,使用uuid究竟有什麼壞處?本篇部落格我們就來分析這個問題,一下內部的原因。1.1 要...

為什麼不推薦使用外來鍵?

外來鍵的優點 一 資料一致性 由資料庫自身保證資料一致性 完整性會更可靠,程式很難100 保證資料的一致性 完整性 二 er圖可靠性 有主外來鍵的資料庫設計可以增加er圖的可讀性 外來鍵的缺點 一 級聯問題 阿里巴巴的開發手冊中,就曾指出強制要求不允許使用外來鍵,一切外來鍵概念必須在應用層解決。因為...