Performance Tuning with SQL Server Dynamic Management Views

High selectivity
Chapter 5: Indexing Strategy and Maintenance
If you've chosen a low selectivity column for the index key (i.e. where each key value
matches many rows), then the optimizer may decide to simply perform a table scan to
return a piece of data. Table scans have a bad reputation, but this is because they often
mean reading a huge number of rows; in small tables, scanning all the rows is sometimes
quicker than reading the data from the leaf levels of an index.
You're looking for selective columns to form your index key and, certainly, the leading
(first) column should be selective. However, this does not mean each index should
start with the PK column; it must be a column that is likely to get searched on.
A good discussion of index selectivity and column ordering can be found at http://
sqlserverpedia.com/wiki/Index_Selectivity_and_Column_Order.
Neither too many nor too few
The drive to cover queries does not mean you should simply create an index for
every query in your workload. If a table contains many rows and is subject to frequent
modifications, the presence of numerous indexes will significantly slow down these modifications,
as the data must be maintained in both the index and the underlying table.
Examine the workload characteristics for a given table as this will affect how many
indexes you might want to have per table. If a table is pretty static, you can manage with
more indexes, but on tables subject to frequent updates, you'll want as few as you can get
away with.
Narrow indexes (within reason)
Neither does the drive to cover queries mean that you should create huge, 16-column
indexes in an attempt to "cover everything at once;" if your index key values are wide,
181