最近用戶報(bào)告某操作極為耗時(shí)，經(jīng)查，是取一個(gè)較復(fù)雜的視圖的記錄數(shù)引起的，相應(yīng)select語(yǔ)句及視圖定義類似于：

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;

三個(gè)表tab1, tab2, tab3的主鍵均為ID，其中tab1的字段FLAG只有0,1,2等有限個(gè)值。當(dāng)三個(gè)表的數(shù)據(jù)達(dá)到2000萬(wàn)級(jí)時(shí)，耗時(shí)在100s以上。分析執(zhí)行計(jì)劃，發(fā)現(xiàn)因?yàn)橛辛藯l件“tab1.FLAG<>1”，而需要執(zhí)行對(duì)tab1的全表掃描。

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

在進(jìn)行多次嘗試之后，終于找到一種方法實(shí)現(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í)行計(jì)劃，不再有tab1的全表掃描，并且已經(jīng)利用上了剛創(chuàng)建的位圖索引。在2000萬(wàn)級(jí)的情況下，用時(shí)約為2.1s。用戶對(duì)此表示認(rèn)可，問(wèn)題解決。

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

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

總結(jié)

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

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