為什么 MySQL 不推薦使用 join？
點擊上方“程序員大白”，選擇“星標”公眾號
重磅干貨，第一時間送達
來源：cnblogs.com/liboware/p/12740901.html
1.對于mysql，不推薦使用子查詢和join是因為本身join的效率就是硬傷，一旦數(shù)據(jù)量很大效率就很難保證，強烈推薦分別根據(jù)索引單表取數(shù)據(jù)，然后在程序里面做join，merge數(shù)據(jù)。
3.如果是JOIN的話，它是走嵌套查詢的。小表驅動大表，且通過索引字段進行關聯(lián)。如果表記錄比較少的話，還是OK的。大的話業(yè)務邏輯中可以控制處理。
4.數(shù)據(jù)庫是最底層的，瓶頸往往是數(shù)據(jù)庫。建議數(shù)據(jù)庫只是作為數(shù)據(jù)store的工具，而不要添加業(yè)務上去。
一、應用層關聯(lián)的優(yōu)勢
讓緩存的效率更高。許多應用程序可以方便地緩存單表查詢對應的結果對象。如果關聯(lián)中的某個表發(fā)生了變化，那么就無法使用查詢緩存了，而拆分后，如果某個表很少改變，那么基于該表的查詢就可以重復利用查詢緩存結果了。
將查詢分解后，執(zhí)行單個查詢可以減少鎖的競爭。 在應用層做關聯(lián)，可以更容易對數(shù)據(jù)庫進行拆分，更容易做到高性能和可擴展。 查詢本身效率也可能會有所提升。查詢id集的時候，使用IN（）代替關聯(lián)查詢，可以讓MySQL按照ID順序進行查詢，這可能比隨機的關聯(lián)要更高效。 可以減少冗余記錄的查詢。在應用層做關聯(lián)查詢，意味著對于某條記錄應用只需要查詢一次，而在數(shù)據(jù)庫中做關聯(lián)查詢，則可能需 要重復地訪問一部分數(shù)據(jù)。從這點看，這樣的重構還可能會減少網(wǎng)絡和內存的消艷。 更進一步，這樣做相當于在應用中實現(xiàn)了哈希關聯(lián)，而不是使用MySQL的嵌套循環(huán)關聯(lián)。某些場景哈希關聯(lián)的效率要高很多。
二、應用層關聯(lián)的使用場景
當應用能夠方便地緩存單個查詢的結果的時候 當可以將數(shù)據(jù)分布到不同的MySQL服務器上的時候 當能夠使用IN（）的方式代替關聯(lián)查詢的時候 并發(fā)場景多，DB查詢頻繁，需要分庫分表
三、不推薦使用join的原因
1.DB承擔的業(yè)務壓力大，能減少負擔就減少。當表處于百萬級別后，join導致性能下降；
2.分布式的分庫分表。這種時候是不建議跨庫join的。目前mysql的分布式中間件，跨庫join表現(xiàn)不良。
3.修改表的schema，單表查詢的修改比較容易，join寫的sql語句要修改，不容易發(fā)現(xiàn)，成本比較大，當系統(tǒng)比較大時，不好維護。
推薦閱讀：圖解 5 種 Join 連接及實戰(zhàn)案例
四、不使用join的解決方案
在業(yè)務層，單表查詢出數(shù)據(jù)后，作為條件給下一個單表查詢。也就是子查詢。會擔心子查詢出來的結果集太多。mysql對in的數(shù)量沒有限制，但是mysql限制整條sql語句的大小。
通過調整參數(shù)max_allowed_packet ，可以修改一條sql的最大值。建議在業(yè)務上做好處理，限制一次查詢出來的結果集是能接受的。
五、join查詢的優(yōu)勢
關聯(lián)查詢的好處是可以做分頁，可以用副表的字段做查詢條件，在查詢的時候，將副表匹配到的字段作為結果集，用主表去in它。
但是問題來了，如果匹配到的數(shù)據(jù)量太大就不行了，也會導致返回的分頁記錄跟實際的不一樣，解決的方法可以交給前端，一次性查詢，讓前端分批顯示就可以了，這種解決方案的前提是數(shù)據(jù)量不太，因為sql本身長度有限。
推薦閱讀
國產小眾瀏覽器因屏蔽視頻廣告，被索賠100萬（后續(xù)）
年輕人“不講武德”：因看黃片上癮，把網(wǎng)站和786名女主播起訴了
關于程序員大白
程序員大白是一群哈工大，東北大學，西湖大學和上海交通大學的碩士博士運營維護的號，大家樂于分享高質量文章，喜歡總結知識，歡迎關注[程序員大白]，大家一起學習進步！