最近用戶報告某操作極為耗時，經(jīng)查，是取一個較復(fù)雜的視圖的記錄數(shù)引起的，相應(yīng)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等有限個值。當(dāng)三個表的數(shù)據(jù)達(dá)到2000萬級時，耗時在100s以上。分析執(zhí)行計劃，發(fā)現(xiàn)因為有了條件“tab1.FLAG<>1”，而需要執(zhí)行對tab1的全表掃描。

考慮到FLAG的情況，首先在其上創(chuàng)建了一個位圖索引以期進(jìn)行優(yōu)化。但不幸的是，FLAG=0的記錄大約占全部記錄的98%以上，FLAG=1的情況不足1%，導(dǎo)致優(yōu)化器根本不考慮使用該位圖索引。

在進(jìn)行多次嘗試之后，終于找到一種方法實現(xiàn)了優(yōu)化的目標(biāo)。修改視圖定義如下：?

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的執(zhí)行計劃，不再有tab1的全表掃描，并且已經(jīng)利用上了剛創(chuàng)建的位圖索引。在2000萬級的情況下，用時約為2.1s。用戶對此表示認(rèn)可，問題解決。

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

轉(zhuǎn)載于:https://www.cnblogs.com/wggj/p/10608374.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。