Chapter
4
Deriving the Ideal Index for a SELECT ž ž ž ž ž ž ž ž ž ž
Guidelines for the major performance factors concerning table and index scans Random and sequential read times and CPU costs Assigning stars to an index for a SELECT statement, according to the three most important requirements The design of a three-star index—the ideal index for the statement Fat indexes Algorithm to design the best index for a SELECT statement Consideration of the existing indexes to determine the most practical index, taking into account CPU time, disk read time, and elapsed time Implications of any suggested changes to the current indexes with regard to the maintenance overheads Response time, drive load, and disk costs Recommendations
INTRODUCTION Many DBAs appear to be satisfied if all the SQL calls in a program use one or more index. Everything looks normal; “the EXPLAIN is clean.” An inappropriate index, however, may lead to worse performance than a scan of the whole table. Mark Gurry (2) agrees: I am astounded at how many tuners, albeit inexperienced, believe that if an SQL statement uses an index, it must be well tuned. You should always ask, “Is it the best available index?” or “Could an additional index be added to improve the responsiveness?” or “Would a full table scan produce the result faster?” (page 47)
In this chapter we are going to consider these extremely important questions in considerable detail, but first we will need to define the assumptions on which our analysis will be based. Relational Database Index Design and the Optimizers, by Tapio Lahdenm¨aki and Michael Leach Copyright 2005 John Wiley & Sons, Inc.
47