在where条件中的集合中，Oracle查询中未使用索引

Question

I have a event table with name MyTable , in this table i have MyTableId column on which we have created index. This table is having 70 million rows. Now, i have created a purge proc which purges events based on a table type collection MyTableCollection . the collection have 100 rows limit.So, as a whole we can purge 100 rows at a time. But when I ran the below query in the proc it got stuck for 40 mins.

DELETE  FROM MyTable
            WHERE   MyTableId IN (SELECT MyTableId FROM TABLE(MyTableCollection))

When i ran analyzer on this query with hard coded values, it showed indexed range scan

DELETE  FROM MyTable
                WHERE   MyTableId IN (10,20,30)

Is collection in the query behind the scenes is playing a role of not using index in the query? I am thinking oracle might get confused about the number of rows being fetched in collection. Am I correct ? solution?

PS: I am thinking of implementing FORALL to delete the rows.

Answer 1

When you execute this ...

WHERE   MyTableId IN (10,20,30)

... the optimizer is clever enough to know it's going to hit three rows. But if you do this ...

WHERE   MyTableId IN (SELECT /*+ CARDINALITY(MyTableCollection 3) */MyTableId FROM TABLE(MyTableCollection))

Then it has no idea how many rows are in the collection. So it assumes there are 8192 rows, and chooses the execution plan accordingly.

But you can tell the optimizer how many rows are in the collection, by using the cardinality hint:

WHERE   MyTableId IN (SELECT /*+ CARDINALITY(MyTableCollection 100) */
                      MyTableId FROM TABLE(MyTableCollection))

"This table is having 70 million rows"

By the way, it would be worth checking the freshness of your table's statistics, because we would still expect the optimizer to consider an index to get 8192/70000000 rows.