最近用戶報告某操作極為耗時，經查，是取一個較復雜的視圖的記錄數引起的，相應select語句及視圖定義類似于：

select count(*) from my_view;create or replace my_view as selecttab1.ID, tab1.f1, tab1.f2,tab2.f3, tab2.f4,tab3.f5, tab3.f6 from tab1 left join tab2 on tab1.ID=tab2.ID left join tab3 on tab1.ID=tab3.ID where tab1.FLAG<>1;

三個表tab1, tab2, tab3的主鍵均為ID，其中tab1的字段FLAG只有0,1,2等有限個值。當三個表的數據達到2000萬級時，耗時在100s以上。分析執行計劃，發現因為有了條件“tab1.FLAG<>1”，而需要執行對tab1的全表掃描。

考慮到FLAG的情況，首先在其上創建了一個位圖索引以期進行優化。但不幸的是，FLAG=0的記錄大約占全部記錄的98%以上，FLAG=1的情況不足1%，導致優化器根本不考慮使用該位圖索引。

在進行多次嘗試之后，終于找到一種方法實現了優化的目標。修改視圖定義如下：?

create or replace my_view as selecttab1.ID, tab1.f1, tab1.f2,tab2.f3, tab2.f4,tab3.f5, tab3.f6 from tab1 left join tab2 on tab1.ID=tab2.ID left join tab3 on tab1.ID=tab3.ID where tab1.ID NOT IN (select ID from tab1 where FLAG=1);

再查看select count(*) from my_view的執行計劃，不再有tab1的全表掃描，并且已經利用上了剛創建的位圖索引。在2000萬級的情況下，用時約為2.1s。用戶對此表示認可，問題解決。

?再進一步延伸，對于不支持位圖索引的數據庫（如MySQL），可以另建一張小表存儲FLAG=1的記錄，再將視圖定義里的條件的子查詢改為從該小表取ID即可。

轉載于:https://www.cnblogs.com/wggj/p/10608374.html

總結

以上是生活随笔為你收集整理的一次利用位图索引进行SQL优化的案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。