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
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
When developing tables in a parent-child relationship, use a primary key and a foreign key along with a unique ID to make your database easier to ... Continue Reading
IBM did not change the default of the reuse deleted files function to YES for physical files in order to minimize the impact on any existing ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.