為什么 MySQL 不推薦使用 join？
1、面試被問(wèn)事務(wù)注解 @Transactional 失效怎么解決？ 2、CTO 說(shuō)了，用錯(cuò) @Autowired 和 @Resource 的人可以領(lǐng)盒飯了 3、在項(xiàng)目中用了Arrays.asList、ArrayList的subList，被公開(kāi)批評(píng) 4、這六個(gè) MySQL 死鎖案例，能讓你理解死鎖的原因！ 5、別總寫(xiě)代碼，這130個(gè)網(wǎng)站比漲工資都重要
1.對(duì)于mysql，不推薦使用子查詢和join是因?yàn)楸旧韏oin的效率就是硬傷，一旦數(shù)據(jù)量很大效率就很難保證，強(qiáng)烈推薦分別根據(jù)索引單表取數(shù)據(jù)，然后在程序里面做join，merge數(shù)據(jù)。
2.子查詢就更別用了，效率太差，執(zhí)行子查詢時(shí)，MYSQL需要?jiǎng)?chuàng)建臨時(shí)表，查詢完畢后再刪除這些臨時(shí)表，所以，子查詢的速度會(huì)受到一定的影響，這里多了一個(gè)創(chuàng)建和銷毀臨時(shí)表的過(guò)程。
3.如果是JOIN的話，它是走嵌套查詢的。小表驅(qū)動(dòng)大表，且通過(guò)索引字段進(jìn)行關(guān)聯(lián)。如果表記錄比較少的話，還是OK的。大的話業(yè)務(wù)邏輯中可以控制處理。
4.數(shù)據(jù)庫(kù)是最底層的，瓶頸往往是數(shù)據(jù)庫(kù)。建議數(shù)據(jù)庫(kù)只是作為數(shù)據(jù)store的工具，而不要添加業(yè)務(wù)上去。
一、應(yīng)用層關(guān)聯(lián)的優(yōu)勢(shì)
讓緩存的效率更高。許多應(yīng)用程序可以方便地緩存單表查詢對(duì)應(yīng)的結(jié)果對(duì)象。如果關(guān)聯(lián)中的某個(gè)表發(fā)生了變化，那么就無(wú)法使用查詢緩存了，而拆分后，如果某個(gè)表很少改變，那么基于該表的查詢就可以重復(fù)利用查詢緩存結(jié)果了。
將查詢分解后，執(zhí)行單個(gè)查詢可以減少鎖的競(jìng)爭(zhēng)。 在應(yīng)用層做關(guān)聯(lián)，可以更容易對(duì)數(shù)據(jù)庫(kù)進(jìn)行拆分，更容易做到高性能和可擴(kuò)展。 查詢本身效率也可能會(huì)有所提升。查詢id集的時(shí)候，使用IN（）代替關(guān)聯(lián)查詢，可以讓MySQL按照ID順序進(jìn)行查詢，這可能比隨機(jī)的關(guān)聯(lián)要更高效。 可以減少冗余記錄的查詢。在應(yīng)用層做關(guān)聯(lián)查詢，意味著對(duì)于某條記錄應(yīng)用只需要查詢一次，而在數(shù)據(jù)庫(kù)中做關(guān)聯(lián)查詢，則可能需要重復(fù)地訪問(wèn)一部分?jǐn)?shù)據(jù)。從這點(diǎn)看，這樣的重構(gòu)還可能會(huì)減少網(wǎng)絡(luò)和內(nèi)存的消艷。 更進(jìn)一步，這樣做相當(dāng)于在應(yīng)用中實(shí)現(xiàn)了哈希關(guān)聯(lián)，而不是使用MySQL的嵌套循環(huán)關(guān)聯(lián)。某些場(chǎng)景哈希關(guān)聯(lián)的效率要高很多。
二、應(yīng)用層關(guān)聯(lián)的使用場(chǎng)景
當(dāng)應(yīng)用能夠方便地緩存單個(gè)查詢的結(jié)果的時(shí)候 當(dāng)可以將數(shù)據(jù)分布到不同的MySQL服務(wù)器上的時(shí)候 當(dāng)能夠使用IN（）的方式代替關(guān)聯(lián)查詢的時(shí)候 并發(fā)場(chǎng)景多，DB查詢頻繁，需要分庫(kù)分表
三、不推薦使用join的原因
1.DB承擔(dān)的業(yè)務(wù)壓力大，能減少負(fù)擔(dān)就減少。當(dāng)表處于百萬(wàn)級(jí)別后，join導(dǎo)致性能下降；
2.分布式的分庫(kù)分表。這種時(shí)候是不建議跨庫(kù)join的。目前mysql的分布式中間件，跨庫(kù)join表現(xiàn)不良。
3.修改表的schema，單表查詢的修改比較容易，join寫(xiě)的sql語(yǔ)句要修改，不容易發(fā)現(xiàn)，成本比較大，當(dāng)系統(tǒng)比較大時(shí)，不好維護(hù)。
四、不使用join的解決方案
在業(yè)務(wù)層，單表查詢出數(shù)據(jù)后，作為條件給下一個(gè)單表查詢。也就是子查詢。會(huì)擔(dān)心子查詢出來(lái)的結(jié)果集太多。mysql對(duì)in的數(shù)量沒(méi)有限制，但是mysql限制整條sql語(yǔ)句的大小。
通過(guò)調(diào)整參數(shù)max_allowed_packet ，可以修改一條sql的最大值。建議在業(yè)務(wù)上做好處理，限制一次查詢出來(lái)的結(jié)果集是能接受的。
五、join查詢的優(yōu)勢(shì)
關(guān)聯(lián)查詢的好處是可以做分頁(yè)，可以用副表的字段做查詢條件，在查詢的時(shí)候，將副表匹配到的字段作為結(jié)果集，用主表去in它。
但是問(wèn)題來(lái)了，如果匹配到的數(shù)據(jù)量太大就不行了，也會(huì)導(dǎo)致返回的分頁(yè)記錄跟實(shí)際的不一樣，解決的方法可以交給前端，一次性查詢，讓前端分批顯示就可以了，這種解決方案的前提是數(shù)據(jù)量不太，因?yàn)閟ql本身長(zhǎng)度有限。
最近熱文閱讀：
1、終于來(lái)了，IDEA 2021.1版本正式發(fā)布，完美支持WSL 2 2、面試被問(wèn)事務(wù)注解 @Transactional 失效怎么解決？ 3、CTO 說(shuō)了，用錯(cuò) @Autowired 和 @Resource 的人可以領(lǐng)盒飯了 4、在項(xiàng)目中用了Arrays.asList、ArrayList的subList，被公開(kāi)批評(píng) 5、別總寫(xiě)代碼，這130個(gè)網(wǎng)站比漲工資都重要 6、哇！IntelliJ IDEA 2021.1 中竟然有這么多牛逼的插件~ 7、能掙錢(qián)的，開(kāi)源 SpringBoot 商城系統(tǒng)，功能超全，超漂亮，真TMD香！ 8、放棄 Notepad++，事實(shí)證明，還有 5 款更牛逼…… 9、公司這套架構(gòu)統(tǒng)一處理 try...catch 這么香，求求你不要再滿屏寫(xiě)了，再發(fā)現(xiàn)扣績(jī)效！ 10、Spring 中經(jīng)典的 9 種設(shè)計(jì)模式！收藏了 關(guān)注公眾號(hào)，你想要的Java都在這里