對於mysql，不推薦使用子查詢和join是因為本身join的效率就是硬傷，一旦數據量很大效率就很難保證，強烈推薦分別根據索引單表取數據，然後在程式裏面做join，merge數據。
子查詢就更別用了，效率太差，執行子查詢時，MYSQL需要建立臨時表，查詢完畢後再刪除這些臨時表，所以，子查詢的速度會受到一定的影響，這裏多了一個建立和銷毀臨時表的過程。
如果是JOIN的話，它是走巢狀查詢的。小表驅動大表，且透過索引欄位進行關聯。如果表記錄比較少的話，還是OK的。大的話業務邏輯中可以控制處理。
資料庫是最底層的，瓶頸往往是資料庫。建議資料庫只是作為數據store的工具，而不要添加業務上去。
一、套用層關聯的優勢
讓緩存的效率更高。許多應用程式可以方便地緩存單表查詢對應的結果物件。如果關聯中的某個表發生了變化，那麽就無法使用查詢緩存了，而拆分後，如果某個表很少改變，那麽基於該表的查詢就可以重復利用查詢緩存結果了。另外，關於mysql更多面試資料，公眾號Java精選，回復Java面試，獲取線上面試資料，支持隨時隨地刷題。
將查詢分解後，執行單個查詢可以減少鎖的競爭。
在套用層做關聯，可以更容易對資料庫進行拆分，更容易做到高效能和可延伸。
查詢本身效率也可能會有所提升。查詢id集的時候，使用IN（）代替關聯查詢，可以讓MySQL按照ID順序進行查詢，這可能比隨機的關聯要更高效。
可以減少冗余記錄的查詢。在套用層做關聯查詢，意味著對於某條記錄套用只需要查詢一次，而在資料庫中做關聯查詢，則可能需
要重復地存取一部份數據。從這點看，這樣的重構還可能會減少網路和記憶體的消艷。
更進一步，這樣做相當於在套用中實作了哈希關聯，而不是使用MySQL的巢狀迴圈關聯。某些場景哈希關聯的效率要高很多。
二、套用層關聯的使用場景
當套用能夠方便地緩存單個查詢的結果的時候
當可以將數據分布到不同的MySQL伺服器上的時候
當能夠使用IN（）的方式代替關聯查詢的時候
並行場景多，DB查詢頻繁，需要分庫分表
三、不推薦使用join的原因
1.DB承擔的業務壓力大，能減少負擔就減少。當表處於百萬級別後，join導致效能下降；
2.分布式的分庫分表。這種時候是不建議跨庫join的。目前mysql的分布式中介軟體，跨庫join表現不良。
3.修改表的schema，單表查詢的修改比較容易，join寫的sql語句要修改，不容易發現，成本比較大，當系統比較大時，不好維護。
四、不使用join的解決方法
在業務層，單表查詢出數據後，作為條件給下一個單表查詢。也就是子查詢。會擔心子查詢出來的結果集太多。mysql對in的數量沒有限制，但是mysql限制整條sql語句的大小。
透過調整參數max_allowed_packet ，可以修改一條sql的最大值。建議在業務上做好處理，限制一次查詢出來的結果集是能接受的。
五、再來說說join查詢的好處
關聯查詢的好處是可以做分頁，可以用副表的欄位做查詢條件，在查詢的時候，將副表匹配到的欄位作為結果集，用主表去in它。
但是問題來了，如果匹配到的數據量太大就不行了，也會導致返回的分頁記錄跟實際的不一樣，解決的方法可以交給前端，一次性查詢，讓前端分批顯示就可以了，這種解決方案的前提是數據量不太，因為sql本身長度有限。
來源：cnblogs.com/libowa
re/p/12740901.html
>>
END
精品資料，超贊福利，免費領
微信掃碼/長按辨識 添加【技術交流群】
群內每天分享精品學習資料
最近開發整理了一個用於速刷面試題的小程式；其中收錄了上千道常見面試題及答案(包含基礎、並行、JVM、MySQL、Redis、Spring、SpringMVC、SpringBoot、SpringCloud、訊息佇列等多個型別)，歡迎您的使用。
👇👇
👇點選"閱讀原文"，獲取更多資料（持續更新中）
