Indexes: An Overview and Maintenance for Performance

Many people know the importance of creating indexes on SQL Server database tables. Indexes greatly improve the performance of a database. However, while many people create indexes on their SQL Server tables, many people don't maintain them properly to ensure queries run efficiently as possible. I'll begin by giving a quick overview of how SQL Server 2000 stores data and how indexes improve performance. Then, I'll spend quite a bit of time explaining why, when, and how to maintain indexes with DBCC SHOWCONTIG and DBCC INDEXDEFRAG to ensure queries run in the most efficient manner. SQL Server 2000 stores data into what is known as a heap. A heap is a collection of data pages containing rows for a table. The data isn't stored in any particular order and the data pages themselves aren't in any sequential order. The data is just there with no real form or organization. When SQL Server accesses data in this form, it does a table scan. This means SQL Server starts reading at the beginning of the table and scans every page until it finds the data that meets the criteria of the query. If a table is very large, this could greatly decrease the performance of queries. Indexes will hasten the retrieval of data. It is important to understand how data is used, the types of queries being performed and the frequency of the queries that are typically performed when planning to create indexes. An index is far more efficient when the query results return a low percentage of rows and the selectivity is high. High selectivity means a query is written so it returns the lowest number of rows possible. As a rule, indexes should be created on columns that are commonly searched; this includes primary and foreign keys. It follows that columns that contain few unique values should never be indexed; this will increase the number of rows returned in a query. There are two types of indexes to consider when planning: Non-Clustered and Clustered Indexes. A non-clustered index stores data comparable to the index of a text book. The index is created in a different location than the actual data. The structure creates an index with a pointer that points to the actual location of the data. Non-clustered indexes should be created on columns where the selectivity of query ranges from highly selective to unique. These indexes are useful when providing multiple ways to search data is desired. A clustered index stores data similar to a phone directory where all people with the same last name are grouped together. SQL Server will quickly search a table with a clustered index while the index itself determines the sequence in which rows are stored in a table. Clustered indexes are useful for columns searched frequently for ranges of values, or are accessed in sorted order. Each table can have only one clustered index, however up to 249 clustered indexes can be added per table. For more information on how Clustered and Non-Clustered indexes store data visit DBCC DBREINDEX (member, '', 80) DBCC DBREINDEX (provider, '', 80) Running the queries: DBCC SHOWCONTIG (member) WITH ALL_INDEXES DBCC SHOWCONTIG (provider) WITH ALL_INDEXES DBCC SHOWCONTIG scanning 'member' table... Table: 'member' (786101841); index ID: 2, database ID: 14 LEAF level scan performed. - Pages Scanned................................: 41 - Extents Scanned..............................: 6 - Extent Switches..............................: 5 - Avg. Pages per Extent........................: 6.8 - Scan Density [Best Count:Actual Count].......: 100.00% [6:6] - Logical Scan Fragmentation ..................: 0.00% - Extent Scan Fragmentation ...................: 0.00% - Avg. Bytes Free per Page.....................: 1657.0 - Avg. Page Density (full).....................: 79.53% DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC SHOWCONTIG scanning 'provider' table... Table: 'provider' (850102069); index ID: 2, database ID: 14 LEAF level scan performed. - Pages Scanned................................: 2 - Extents Scanned..............................: 2 - Extent Switches..............................: 1 - Avg. Pages per Extent........................: 1.0 - Scan Density [Best Count:Actual Count].......: 50.00% [1:2] - Logical Scan Fragmentation ..................: 0.00% - Extent Scan Fragmentation ...................: 0.00% - Avg. Bytes Free per Page.....................: 4346.0 - Avg. Page Density (full).....................: 46.31% DBCC execution completed. If DBCC printed error messages, contact your system administrator. As a result of running the DBCC SHOWCONTIG and DBCC INDEXDEFRAG commands, we were able to diagnose and greatly reduce fragmentation on the 'member' and 'provider' tables. The member table is almost perfect and the 'provider' table shows great improvement. This will result in an extraordinary performance increase on queries that are run against these tables. *For more information on fragmentation, visit this link: