mysqlleftjoin會(huì)影響數(shù)據(jù)庫(kù)性能嗎？只要索引使用得當(dāng)，簡(jiǎn)單的left join是不會(huì)影響數(shù)據(jù)庫(kù)查詢(xún)性能的，但有幾種情況要特殊考慮下：1. 聯(lián)表查詢(xún)涉及到的表超過(guò)了3個(gè)，最好不要使用join，

mysqlleftjoin會(huì)影響數(shù)據(jù)庫(kù)性能嗎？

只要索引使用得當(dāng)，簡(jiǎn)單的left join是不會(huì)影響數(shù)據(jù)庫(kù)查詢(xún)性能的，但有幾種情況要特殊考慮下：

1. 聯(lián)表查詢(xún)涉及到的表超過(guò)了3個(gè)，最好不要使用join，這是《阿里巴巴Java開(kāi)發(fā)規(guī)范》明確說(shuō)明的。

2. 涉及到分庫(kù)分表的，也要慎用join（多表join一時(shí)爽，垂直拆分火葬場(chǎng)）

在平時(shí)的開(kāi)發(fā)中，我一般的做法是能不用join就不用join，能使用Redis和本地緩存的就使用Redis和本地緩存，盡量避免因復(fù)雜的SQL運(yùn)算造成數(shù)據(jù)庫(kù)查詢(xún)性能降低的操作。

left join效率為什么低？

為什么子查詢(xún)比連接查詢(xún)（LEFT JOIN）效率低

MySQL從4.1版本開(kāi)始支持子查詢(xún)，使用子查詢(xún)進(jìn)行SELECT語(yǔ)句嵌套查詢(xún)，可以一次完成很多邏輯上需要多個(gè)步驟才能完成的SQL操作。子查詢(xún)雖然很靈活，但是執(zhí)行效率并不高。

那么問(wèn)題來(lái)了，什么是子查詢(xún)？為什么它的效率不高？

子查詢(xún)：把內(nèi)層查詢(xún)結(jié)果當(dāng)作外層查詢(xún)的比較條件

示例：

select goods_id，goods_name from goods where goods_id = (select max(goods_id) from goods)

執(zhí)行子查詢(xún)時(shí)，MYSQL需要?jiǎng)?chuàng)建臨時(shí)表，查詢(xún)完畢后再刪除這些臨時(shí)表，所以，子查詢(xún)的速度會(huì)受到一定的影響，這里多了一個(gè)創(chuàng)建和銷(xiāo)毀臨時(shí)表的過(guò)程。

優(yōu)化方式：

可以使用連接查詢(xún)（JOIN）代替子查詢(xún)，連接查詢(xún)不需要建立臨時(shí)表，因此其速度比子查詢(xún)快。

mysql一張大表，一張小表，如何join最快？

rows代表這個(gè)步驟相對(duì)上一步結(jié)果的每一行需要掃描的行數(shù)，可以看到這個(gè)sql需要掃描的行數(shù)為35773*8134，非常大的一個(gè)數(shù)字。本來(lái)c和h表的記錄條數(shù)分別為40000 和10000 ，這幾乎是兩個(gè)表做笛卡爾積的開(kāi)銷(xiāo)了（select * from c，h）。

于是我上網(wǎng)查了下MySQL實(shí)現(xiàn)join的原理，原來(lái)MySQL內(nèi)部采用了一種叫做 nested loop join的算法。Nested Loop Join 實(shí)際上就是通過(guò)驅(qū)動(dòng)表的結(jié)果集作為循環(huán)基礎(chǔ)數(shù)據(jù)，然后一條一條的通過(guò)該結(jié)果集中的數(shù)據(jù)作為過(guò)濾條件到下一個(gè)表中查詢(xún)數(shù)據(jù)，然后合并結(jié)果。如果還有第三個(gè)參與 Join，則再通過(guò)前兩個(gè)表的 Join 結(jié)果集作為循環(huán)基礎(chǔ)數(shù)據(jù)，再一次通過(guò)循環(huán)查詢(xún)條件到第三個(gè)表中查詢(xún)數(shù)據(jù)，如此往復(fù)，基本上MySQL采用的是最容易理解的算法來(lái)實(shí)現(xiàn)join。所以驅(qū)動(dòng)表的選擇非常重要，驅(qū)動(dòng)表的數(shù)據(jù)小可以顯著降低掃描的行數(shù)。