Even though the query optimizer advises creating an index, it doesn't always choose to use it when creating its access plan. One reason for this is that the query optimizer does not always advise the perfect index. This is because 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 that query will return many rows, and 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 here.
Dig Deeper on DB2 UDB (universal databases)
Related Q&A from Kent Milligan
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
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
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.