I used to track this down using the EXPLAIN facility. I'd look for
predicates that should use indexes and investigate why they didn't.
Locating non length-matching predicates may or may not be of value
because changes to the optimizer over a period of many years have
improved its ability to handle these differences.
To fully automate what you state you want to do will require parsing the
actual SQL statements, analyzing their column use and attributes in the
predicates, and determining if an index would be appropriate to use. Of
course, you need to determine if it's better to use the index or perform
a scan. You'll also need to determine how to handle multiple column
indexes. By the time you get finished, you will have written a fair
portion of the optimizer.
Many years ago, I did this by hand for a single SQL statement that
wouldn't use an index that should have been used. After many, many hours
of investigation, we discovered that the performance analysis tool that
was being used couldn't spot that the predicate's data area definition
in the program didn't match the length as defined in the table and index.
Phil Sherman
> Hi All,
>
[quoted text clipped - 17 lines]
>
> Bill
wfs - 09 Mar 2006 01:45 GMT
Thanks
Bill
>I used to track this down using the EXPLAIN facility. I'd look for
>predicates that should use indexes and investigate why they didn't.
[quoted text clipped - 40 lines]
>>
>> Bill