Clustered Index and Non-Clustered Index

Clustered Index Vs. Non-Clustered Index In SQL Server

http://www.devtoolshed.com/content/clustered-index-vs-non-clustered-index-sql-server

Those new to SQL Server performance tuning or database indexes in general are probably confused by the differences between clustered and non-clustered indexes. Usually, there is a performance problem that prompts research and you finally have to "bite the bullet"
and look into what the hell these index types are.

What is a Database Index?

First, it is important to understand what an index is and why you need to know about them. The simplest way to think about indexes is that they are "copies" of your data in a table that is sorted a certain way. For instance, if you had a table that looked something
like this:

Let's say this table has 100,000's of rows and you need to query by LastName in most of your queries. By default, when you create this table, your data will be stored on disk and sorted by the "Id" primary key column. This default sort is called the "Clustered
Index". Queries for LastName will be slower though because the data is not sorted by LastName so a SELECT statement will have to do a "full table scan" to find the record you are looking for. You could really speed up these queries that search by LastName
if you were to have the data sorted by LastName instead of by Primary Key.

Another way to speed up your LastName queries is to add a "secondary index" called a "Non-clustered" index. This will make a copy of your table data and store it on disk but will have it sorted by LastName instead of primary key. Now, when you do a select where
LastName = "something", SQL Server's query optimizer is smart enough to know to use your "copy" of your table to search for LastName because it is sorted by that column instead of just table scanning.

Clustered Indexes

There is only 1 clustered index allowed per table so choose wisely. This index should be the most common column that is in your WHERE clauses for queries against this table. So if most of the time you search by primary key, then leave it as the default. But
if you search by DateCreated or LastName most of the time on this table, then you might want to consider changing the clustered index to this column instead.

Some things to remember when using clustered indexes:

The reordering of the index occurs every time the index changes (ie: on Updates, Inserts, Deletes).

Affects the physical order of data so there can only one clustered index.

Keeps the rows in order within a page (8k) of data. The pages are not physically ordered except after an ordered load or re-index based on that cluster.

Re-orders the way records in the table are physically stored.

Choose this index wisely as there can only be one. Rule of thumb: Apply to a unique, somewhat ordered, and commonly queried column.

Like the pages of content in a book. Each page is a collection of data. The order (page numbers 1, 2, 3, etc.) that the data is stored in is controlled by the clustered index.

There a few things to keep in mind when changing the default clustered index in a table:

Lookups from non-clustered indexes must look up the query pointer in the clustered index to get the pointer to the actual data records instead of going directly to the data on disk (usually this performance hit is negligble).

Inserts will be slower because the insert must be added in the exact right place in the clustered index. (NOTE: This does not re-order the data pages. It just inserts the record in the correct order in the page that it corresponds to. Data pages are stored
as doubly-linked lists so each page is pointed to by the previous and next. Therefore, it is not important to reorder the pages, just their pointers and that is only in the case where the newly inserted row causes a new data page to be created.)

Best Practices for Clustered Indexes

Large amount of selects on a table, create a clustered index on the primary key of the table. Then create non-clustered indexes for all other columns used in selects and searches. Put non-clustered indexes on foreign key/primary key columns that are used in
joins.

Non-clustered Indexes

Non-clustered indexes are not copies of the table but a sorting of the columns you specify that "point" back to the data pages in the clustered index. This is why the clustered index you choose is so important because if effects all other indexes.

There are 2 modes for non-clustered indexes, Non-unique and unique. Non-Unique means that the index does not act as a constraint on the table and does not prevent identical rows from being inserted. Unique constraints mean that the index prevents any identical
rows from being inserted.

Does not re-order the actual table data.

Sometimes called a "heap table" for tables lacking clustered indexes because it points to the actual data pages that are essentially unordered and non-indexed.

If no clustered index, non-clustered indexes point to the actual data in the table.

If clustered index present, non-clustered index point to clustered index.

Logical order of the index does not match the physical stored order of the rows on disk.

Similar to an index in the back of a book. The actual data is stored in the pages of the book but the index reorders and stores a pointer to each data value.

Best Practices for Non-clustered Indexes

Add non-clustered indexes for queries that return smaller result sets. Large results will have to read more table pages anyway so they will not benefit as much from a non-clustered index.

Add to columns used in WHERE clauses that return exact matches.

If a clustered index is not used on these columns, add an index for collections of distinct values that are commonly queried such as a first and last name column group.

Add for all columns grouped together for a given query that is expensive or very common on a large data table.

Add to foreign-key columns where joins are common that are not covered by the clustered index.

Indexes are a lot of "trial and error" depending on your database design, SQL queries, and database size.