Beginning SQL

On the other hand, an index on a true/false field is not so useful, again depending on the data in the
field. If the distribution is 50/50, then you return half of the records. If the distribution is 5% true and
95% false, and you are searching for true, then the index might help. The problem in a case like this is
that the DBMS may incorrectly assume that the index is going to return so many records that it simply
ignores the index when it performs the query optimize phase. If that happens, then you have a query
that takes up space on the disk (and has to be updated on inserts or changes) but is never used.
I have read that in cases where the distribution is 50/50, it is better just to leave the column nonindexed
and use a table scan to find the data. I find this difficult to believe, at least on large tables, since the disk
I/O to search through an index and pull out all of the pointers to the records on the disk would seem to
be much less than the disk I/O to search through every record. Remember that any index column has
just the column data plus the pointer to the record, and therefore an index tends to be very compact relative
to the table itself and thus can stay in the cache longer.
If you are using this index by itself and you are pulling a 50/50 mix, then that may very well be true
since you have to perform the disk I/O anyway to retrieve all those records. However, if you are using
the index in conjunction with other indexes to narrow down and pull only a small set of records off the
disk, then having the index saves the work of actually looking in each data record to see whether it
matches the search criteria.
Indexes in general tend to be used often, and thus they stay in the cache. In addition, the actual data
pulled from using indexes tends to be cached better since only those rows actually used get pulled into
the cache. Since you aren’t pulling huge blocks of data, you aren’t inadvertently flushing the cache of
useful data. Indexed reads only examine the exact pieces of the bigger data block containing the data
records, reducing the amount of CPU time spent examining the data. And finally, indexed reads can
scale up as the table size grows, giving stable and consistent results for data retrieval, even when the
table itself grows huge.
Table Scans — What Are They?
Database Tuning
As the name implies, a table scan is where the DBMS has to physically retrieve every record in the table
to examine one or more columns to see whether the data in that column matches a join or WHERE condition.
A table scan is what happens when no index exists on a column that has to be compared to something
else in a query. In the absence of an index, the DBMS scans the table, looking at the data item in
that field in every record in the table.
Data is usually organized in sectors, with multiple grouped sectors called extents. In SQL Server, for
example, it is common for the database to use 8K blocks (the maximum size of a data record) with eight
of these blocks read or written at one time by the database, resulting in 64K of data being read or written
at once. See Figure 13-5 for an illustration of a table scan.
361