20.07.2013 Views

Beginning SQL

Beginning SQL

Beginning SQL

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 13<br />

Try It Out Dropping Indexes<br />

Follow these steps to drop an index and perform a bulk import:<br />

1. The assumption here is that an index was created on the ZipCode field of the MemberDetails<br />

table using the following <strong>SQL</strong> syntax:<br />

USE FILMCLUB<br />

CREATE INDEX IND_ZIP<br />

ON MemberDetails (ZipCode)<br />

2. You are getting ready to merge thousands of new members from a membership drive that the<br />

club held last month. Before performing the bulk import, you want to remove the index on the<br />

table. Use the following <strong>SQL</strong> to remove the index:<br />

USE FILMCLUB<br />

DROP INDEX MemberDetails.IND_ZIP<br />

3. Now you can perform the bulk import of the new members. Having done that, you now want<br />

to replace any indexes that you dropped. To do so, use this <strong>SQL</strong>:<br />

USE FILMCLUB<br />

CREATE INDEX IND_ZIP<br />

ON MemberDetails (ZipCode)<br />

How It Works<br />

The DROP INDEX statement completely deletes all traces of the index mentioned in the statement.<br />

Having done that, any subsequent data changes to the column that previously had the index on it no<br />

longer cause the data shuffle slowdown issue, as that slowdown was caused by shuffling the data item<br />

pointers in the index that you deleted. Once all the massive data manipulations have been accomplished,<br />

the index is created from scratch using the CREATE INDEX statement.<br />

If you are going to delete indexes, just be very sure that you re-create them all. If you are not the only<br />

developer in the database, the index you drop may be used by other developers’ queries, and forgetting<br />

to re-create the indexes would wreak havoc with your associates.<br />

Indexes — When They Help, Hurt, or Don’t Matter<br />

360<br />

The generic advice on indexes is to index any column used in a table join or in any WHERE clause. Join<br />

columns probably should always be indexed. The WHERE clause advice is more iffy and plays back into<br />

the question of whether the good outweighs the bad.<br />

Indexes are extremely useful when they are on a field containing data with relatively small data duplication.<br />

A social security number index is an example where an index returns a single row (hopefully), and<br />

it is the best return on investment you can get. In a database of 60 million U.S. addresses, a zip code<br />

index returns a few thousand records, which is a tiny percent of the total records in the database, again a<br />

great return on investment.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!