ユーザ操作の最近の報告は非常に時間がかかり、検査時に、対応するselect文、ビュー定義によって引き起こされたレコードの数のより複雑な見方をするのは、次のようになります。
SELECT COUNT（*）my_viewから。
my_viewを作成したり、交換する
選択として
tab1.ID、tab1.f1、tab1.f2、
tab2.f3、tab2.f4、
tab3.f5、tab3.f6は
TAB1から
tab1.ID = tab2.IDにTAB2に参加左
にTAB3に参加左tab1.ID = tab3.ID
tab1.FLAG <> 1。
3つのテーブルTAB1、主キーTAB2、TAB3はtab1の0,1,2他の有限値FLAGをフィールドID、です。データを20百万円の3つのテーブルに到達すると、数百以上にかかりました。実施計画の分析と理由条件の「tab1.FLAG <> 1」、およびTAB1の全表スキャンを実行する必要があることを発見しました。
最適化するために、ビットマップ索引を作成するには、最初にどのFLAGは、考慮に入れます。残念ながら、FLAG = 0のレコードがビットマップ索引の使用を検討していないオプティマイザにつながる、1％未満の場合、すべてのレコードの約98％、FLAG = 1を占めました。
いくつかの試みを行った後、最終的に最適な目標を達成するための方法を見つけました。次のようにビューが定義されている変更します。
my_viewを作成したり、交換する
選択として
tab1.ID、tab1.f1、tab1.f2、
tab2.f3、tab2.f4、
tab3.f5、tab3.f6は
TAB1から
tab1.ID = tab2.IDにTAB2に参加左
にTAB3に参加左tab1.ID = tab3.ID
ここtab1.ID NOT IN（FLAG = 1 TAB1からIDを選択）。
実施計画my_viewから選択数（*）を見るもはや全表スキャンTAB1を持っていない、と先ほど作成したビットマップ索引を使用していました。2000万例では、約2.1sで使用する場合。ユーザーが承認を表明し、問題が解決されます。
さらに他の別の小さなテーブルストアを構築することができるビットマップ・インデックスをサポートしていないデータベース（例えば、MySQLの）のために、FLAG = 1の場合、ビューの定義は、サブクエリの条件が小さいテーブルIDから取るように変更されたレコード拡張。