Beginning SQL

How Do You Do It?
And herein lies the heart of the matter: How do you optimize a query? As you discovered previously,
optimizing the query may in fact be a matter of optimizing the application itself. There are, however, certain
generally accepted methods for optimizing a query, and in the sections that follow, you start to
examine these specific methods. Indexes are often touted as the be-all and end-all of optimization,
knowing what to index and why. Before you examine these methods, though, it is helpful to get an
overview of how indexes work and how they speed up (or slow down!) a database.
Indexes — What Are They?
Database Tuning
The first thing to understand about indexes is that they are not necessary; they are a convenience used to
speed up accessing data. They are simply a means of getting at a data item in a table without having to
start at the beginning of the table and examine every item in the table. Indexes on static data tables are
essentially free (other than storage costs), but indexes on frequently changing data have very high costs,
as this section explains.
Database indexes are often compared to indexes in a book — a set of references in a table that tell where
in the physical database to go to find a specific item. While it is true that indexes function in the same
manner in databases as they do in books, they are implemented very differently. A book index takes a
word or phrase and gives you a list of pages on which you can find the word.
In databases, however, indexes are usually implemented as a balanced-tree (b-tree) structure, so called
because it looks like an upside-down tree, and the number of data items in each page is kept balanced by
the b-tree engine (see Figure 13-3). In any b-tree, there is a root page that holds pointers to other pages
(called leaves), which hold pointers to other pages, and so forth. Each page holds the data items from the
column being indexed, plus a pointer to the data record holding that item out in the table. To search for
data, the DBMS comes in to the top (root) page and looks for its data there. If it doesn’t find the data, it
looks up which leaf to go to that has data most similar to the data being searched for and then looks
through that leaf page. If it doesn’t find the data there, the DBMS looks for the next leaf down, and so
on. Once the data item is found, the actual pointer to the data record is available to pull the entire record.
By placing a few hundred data items in each page (with pointers to the actual data record for each item
in that page), the total depth of the structure is usually very small. I have heard numbers thrown about
indicating that each page points to as many as 300 other leaves, which means that finding a single record
in a table with up to 27 million records requires searching through only three levels of leaves.
357