MySQL聯(lián)合查詢和簡(jiǎn)單查詢究竟如何選擇?
問題描述
最近看高性能MySQl,里面是推薦把聯(lián)合查詢分解為多個(gè)簡(jiǎn)單的查詢,既然是這樣 那么還要聯(lián)合查詢干嘛?究竟是如何選擇才是效率更高的選擇呢?
問題解答
回答1:簡(jiǎn)單的聯(lián)合查詢一般沒有必要分解,這里所說的應(yīng)該是比較復(fù)雜的聯(lián)合查詢,譬如聯(lián)合查詢3,4張表,如果查詢較為復(fù)雜,涉及到分組,排序什么的,在運(yùn)行時(shí)不能有效利用索引的。甚至有可能產(chǎn)生臨時(shí)表。那效率就會(huì)比較差。而且不利于查詢緩存。分解后針對(duì)每個(gè)簡(jiǎn)單的查詢,數(shù)據(jù)庫(kù)有查詢緩存機(jī)制,會(huì)更加高效。對(duì)聯(lián)合查詢的語句盡量用explain分析一下有哪些問題?針對(duì)性的去改正。該分解的時(shí)候還是要分解。
回答2:select * from tb1left join tb2 on tb1.id=tb2.tidwhere tb1.stat=1 and tb2.stat=1 and tb1.type=1
select * from (select * from tb1 where stat=1 and type=1) as tb1left join tb2 on tb1.id=tb2.tidwhere tb2.stat=1
上面是一個(gè)簡(jiǎn)單的案例, 其實(shí)我不是太明白你說的聯(lián)合查詢分解成多個(gè)簡(jiǎn)單的查詢, 上面只能是我個(gè)人的一些優(yōu)化(分解)方案而已(雖然也并不是每次都是這么用).
如果你所說的分解是將聯(lián)表拆成很多個(gè)語句, 然后在代碼中依次進(jìn)行調(diào)用的話, 相信效率反而比聯(lián)表還低, 每次連接數(shù)據(jù)庫(kù)的 IO 開銷肯定比一次聯(lián)表來的多.
優(yōu)化聯(lián)表查詢效率用一句話來說就是 用最少的正確數(shù)據(jù)進(jìn)行關(guān)聯(lián)
最少的數(shù)據(jù), 就可以通過, 在表進(jìn)行關(guān)聯(lián)前, 提前將正確的數(shù)據(jù)提取出來, 避免關(guān)聯(lián)時(shí)還有很多明顯已經(jīng)知道是錯(cuò)誤的數(shù)據(jù)再去關(guān)聯(lián).
無論是何種 join 方式, 這種方式都能適用.
更多的提高效率方案也還有很多像是 where 的順序, 字段類型, 索引 等等, 這個(gè)范圍就很大了.
回答3:只要用好索引,聯(lián)合查詢沒什么問題
相關(guān)文章:
1. mysql優(yōu)化 - MySQL如何為配置表建立索引?2. 如何用筆記本上的apache做微信開發(fā)的服務(wù)器3. 我在網(wǎng)址中輸入localhost/abc.php顯示的是not found是為什么呢?4. 數(shù)據(jù)庫(kù) - Mysql的存儲(chǔ)過程真的是個(gè)坑!求助下面的存儲(chǔ)過程哪里錯(cuò)啦,實(shí)在是找不到哪里的問題了。5. 關(guān)于mysql聯(lián)合查詢一對(duì)多的顯示結(jié)果問題6. 冒昧問一下,我這php代碼哪里出錯(cuò)了???7. windows誤人子弟啊8. php傳對(duì)應(yīng)的id值為什么傳不了啊有木有大神會(huì)的看我下方截圖9. MySQL主鍵沖突時(shí)的更新操作和替換操作在功能上有什么差別(如圖)10. 實(shí)現(xiàn)bing搜索工具urlAPI提交
