Recent reports of a user operation is extremely time-consuming, and upon inspection, is to take a more complex view of the number of records caused by the corresponding select statement and view definition looks like this:
select count(*) from my_view;
create or replace my_view
as select
tab1.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;
Three tables tab1, primary key tab2, tab3 are ID, where only fields FLAG tab1 0,1,2 other finite values. When the data reaches three tables of 20 million, took in more than 100s. Analysis of the implementation plan and found that because of the condition "tab1.FLAG <> 1", and the need to perform a full table scan of tab1.
Taking into account the FLAG, the first on which to create a bitmap index in order to optimize. Unfortunately, FLAG = 0 records accounted for about 98% of all records, FLAG = 1 in the case of less than 1%, leading to the optimizer does not consider using the bitmap index.
After making several attempts, finally found a way to achieve the optimal goal. Modify the view is defined as follows:
create or replace my_view
as select
tab1.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);
View select count (*) from the implementation plan my_view no longer have a full table scan tab1, and have used the bitmap index just created. In the 20 million cases, about 2.1s when used. Users expressed approval, the problem is solved.
Still further extended, for a database (e.g., MySQL) does not support bitmap index can build a separate small table stores records FLAG = 1, then the view definition the subquery conditions changed to take from the small table ID.