The query optimizer does not always advise the perfect index. The reason for this is that currently, only local selection is used when determining what index to advise -- it does not yet consider join, order by, or group by columns. As a result, after you create that advised index, it may not choose to use it, as it is still not the perfect index. You may need to manually intervene -- examine the query and consider the join, group by, and order by columns to determine what the perfect index is and create that index.
Alternatively, it may be recommending that index so that it can extract stats from the index to further evaluate the optimal access method. For example, once the index has been created, it may be using statistics from the index to determine that query will return many rows, thus a table scan is the least expensive access method.
To better understand the concept of a perfect index and how indexes help the query optimizer with statistics, you can read the Indexing Strategy white paper online here.
MORE INFORMATION ON THIS TOPIC
Visit the ITKnowledge Exchange and get answers to your DB2 questions fast.
Check out this Search400.com Featured Topic: Expert advice on DB2
Search400.com's targeted search engine: Get relevant information on DB2/400.
The Best Web Links: Tips, tutorials and more.
Dig Deeper on DB2 UDB (universal databases)
Related Q&A from Kent Milligan
Create a host variable of the where in statement on the fly with dynamic SQL. Continue Reading
To solve the SQL error -321 on IBM i6.1, use the new values statement to overcome the error. If you are using an older release, declare a cursor ... Continue Reading
When working with DB2 files with columns that have both short and long names, there is no option choose which column names are returned via ODBC ... Continue Reading