先看第乙個問題:能不能使用 join?
如果可以使用 index nested-loop join 演算法，也就是說可以用上被驅動表上的索引， 其實是沒問題的;
如果使用 block nested-loop join 演算法，掃瞄行數就會過多。尤其是在大表上的 join 操作，這樣可能要掃瞄被驅動表很多次，會占用大量的系統資源。所以這種 join 盡量不 要用。
所以你在判斷要不要使用 join 語句時，就是看 explain 結果裡面，extra 字段裡面有沒有 出現「block nested loop」字樣。
我們再來看看第二個問題:怎麼選擇驅動表?
1. 如果是 index nested-loop join 演算法，應該選擇小表做驅動表;
2. 如果是 block nested-loop join 演算法:
在 join_buffer_size 足夠大的時候，是一樣的;
在 join_buffer_size 不夠大的時候(這種情況更常見)，應該選擇小表做驅動表。
所以，這個問題的結論就是，總是應該使用小表做驅動表。
什麼叫作「小表」。
在決定哪個表做驅動表的時候，應該是兩個表按照各自的條件過濾， 過濾完成之後，計算參與 join 的各個欄位的總資料量，資料量小的那個表，就是「小表」，應該作為驅動表。
Oracle Merge語句效率問題
大家一定都會遇到過資料庫操作中的 update,也一定會考慮過主鍵重複的問題,簡單的解決方法就是先 select 然後根據返回值判斷是 insert 還是 update.因為公司要求這個用乙個語句執行,所以調查了 oracle 自身的 merge 語句,針對效率就調查的結果如下 操作次數為 1 時 ...
分頁查詢語句的效率問題
size large b 一般的分頁sql如下所示 b size sql1 select from select t.rownum rn from t where rn 0 and rn 10 sql2 select from select t.rownum rn from t where rown...
SQL語句效率問題的幾點總結
1.sql優化的原則是 將一次操作需要讀取的block數減到最低,即在最短的時間達到最大的資料吞吐量。調整不良sql通常可以從以下幾點切入 檢查不良的sql，考慮其寫法是否還有可優化內容 檢查子查詢 考慮sql子查詢是否可以用簡單連線的方式進行重新書寫 檢查優化索引的使用 考慮資料庫的優化器 2.避...