SQL Server Index Tips

You get exactly one clustered index on a table. Ensure you have it in the right place. First choice is the most frequently accessed column, which may or may not be the primary key. Second choice is a column that structures the storage in a way that helps performance. This is a must for partitioning data.

Clustered indexes work well on columns that are used a lot for ‘range’ WHERE clauses such as BETWEEN and LIKE, where it is frequently used in ORDER BY clauses or in GROUP BY clauses.

If clustered indexes are narrow (involve few columns) then this will mean that less storage is needed for non-clustered indexes for that table.

You do not have to make the primary key the clustered index. This is default behavior but can be directly controlled.

You should have a clustered index on every table in the database. There are exceptions, but the exceptions should be exceptional.

Avoid using a column in a clustered index that has values that are frequently updated.

Only create non-clustered indexes on tables when you know they’ll be used through testing. You can seriously hurt performance by creating too many indexes on a table.

Keep your indexes as narrow as possible. This means reducing the number and size of the columns used in the index key. This helps make the index more efficient.

Always index your foreign key columns if you are likely to delete rows from the referenced table. This avoids a table scan.

A clustered index on a GUID can lead to serious fragmentation of the index due to the random nature of the GUID. You can use the function NEWSEQUENTIALID() to generate a GUID that will not lead to as much fragmentation.

Performance is enhanced when indexes are placed on columns used in WHERE, JOIN, ORDER BY, GROUP, and TOP. Always test to ensure that the index does help performance.

If a non-clustered index is useful to your queries, but doesn’t have all the columns needed by the query, you can consider using the INCLUDE option to store the extra columns at the leaf level of the index.

If temporary tables are in use, you can add indexes to those tables to enhance their performance.

Where possible, make the indexes unique. This is especially true of the clustered index (one of the reasons that the primary key is by default clustered). A unique index absolutely performs faster than a non-unique index, even with the same values.

Ensure that the selectivity of the data in the indexes is high. Very few unique values makes an index much less likely to be used well by the query optimizer.

It is almost always better to let SQL Server update statistics automatically.