MySQL聯(lián)合查詢和簡單查詢究竟如何選擇?
問題描述
最近看高性能MySQl,里面是推薦把聯(lián)合查詢分解為多個簡單的查詢,既然是這樣 那么還要聯(lián)合查詢干嘛?究竟是如何選擇才是效率更高的選擇呢?
問題解答
回答1:簡單的聯(lián)合查詢一般沒有必要分解,這里所說的應該是比較復雜的聯(lián)合查詢,譬如聯(lián)合查詢3,4張表,如果查詢較為復雜,涉及到分組,排序什么的,在運行時不能有效利用索引的。甚至有可能產生臨時表。那效率就會比較差。而且不利于查詢緩存。分解后針對每個簡單的查詢,數(shù)據(jù)庫有查詢緩存機制,會更加高效。對聯(lián)合查詢的語句盡量用explain分析一下有哪些問題?針對性的去改正。該分解的時候還是要分解。
回答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
上面是一個簡單的案例, 其實我不是太明白你說的聯(lián)合查詢分解成多個簡單的查詢, 上面只能是我個人的一些優(yōu)化(分解)方案而已(雖然也并不是每次都是這么用).
如果你所說的分解是將聯(lián)表拆成很多個語句, 然后在代碼中依次進行調用的話, 相信效率反而比聯(lián)表還低, 每次連接數(shù)據(jù)庫的 IO 開銷肯定比一次聯(lián)表來的多.
優(yōu)化聯(lián)表查詢效率用一句話來說就是 用最少的正確數(shù)據(jù)進行關聯(lián)
最少的數(shù)據(jù), 就可以通過, 在表進行關聯(lián)前, 提前將正確的數(shù)據(jù)提取出來, 避免關聯(lián)時還有很多明顯已經知道是錯誤的數(shù)據(jù)再去關聯(lián).
無論是何種 join 方式, 這種方式都能適用.
更多的提高效率方案也還有很多像是 where 的順序, 字段類型, 索引 等等, 這個范圍就很大了.
回答3:只要用好索引,聯(lián)合查詢沒什么問題
相關文章:
1. Docker for Mac 創(chuàng)建的dnsmasq容器連不上/不工作的問題2. PHP求助,求幫忙謝謝各位3. extra沒有加載出來4. mysql - php 如何網址中出現(xiàn)該頁標題?5. javascript - 天貓首頁首屏數(shù)據(jù)來源6. javascript - 釘釘?shù)膃xcel, word文件預覽是直接用的微軟的office web app,不犯法嗎?7. 關于Mysql數(shù)據(jù)表行轉列8. django進行數(shù)據(jù)庫的查詢9. 求救一下,用新版的phpstudy,數(shù)據(jù)庫過段時間會消失是什么情況?10. mysql - 為什么where條件中or加索引不起作用?
