Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Difference of create Index by using include column or not using

Tags:

I Want To Create Index In SQL Server 2008 R2 in Column1 and Column2 What is the difference of below query:

  1. Not include

    CREATE NONCLUSTERED INDEX [IX_1] ON [dbo].[MyTable] 
    (
        [Column1] ASC,
        [Column2] ASC
    ) ON [PRIMARY]
    
  2. Or include:

    CREATE NONCLUSTERED INDEX [IX_2] ON [dbo].[MyTable] 
    (
        [Column1] ASC
    )
    INCLUDE ([Column2]) ON [PRIMARY]
    
like image 852
mehdi lotfi Avatar asked May 31 '12 06:05

mehdi lotfi


People also ask

What is the difference between indexed columns and included columns?

Index key columns are part of the b-tree of the index. Included columns are not. In the first query, index1 provides a mechanism for quickly identifying the rows of interest. The query will (probably) execute as an index seek, followed by a bookmark lookup to retrieve the full row(s).

Why use the include clause when creating an index?

The include clause allows us to make a distinction between columns we would like to have in the entire index (key columns) and columns we only need in the leaf nodes ( include columns). That means it allows us to remove columns from the non-leaf nodes if we don't need them there.

What is include column in index?

Indexes with included columns provide the greatest benefit when covering the query. This means that the index includes all columns referenced by your query, as you can add columns with data types, number or size not allowed as index key columns.

When should an index be created on a column?

In general, you should create an index on a column in any of the following situations: The column is queried frequently. A referential integrity constraint exists on the column. A UNIQUE key integrity constraint exists on the column.


1 Answers

In the first one Column2 gets added to the index key. In the second one it might not (*) get added to the key in which case it will only appear in the index leaf pages. This can allow the index to be searched by Column1 but avoid the need to go back to the base table (bookmark lookup/key lookup) to retrieve the value for Column2.

i.e. it makes index2 "covering" for queries such as

SELECT Column1,Column2
FROM [dbo].[MyTable] 
WHERE Column1 = 'X'

And it also covers queries such as

SELECT Column1,Column2
FROM [dbo].[MyTable] 
WHERE Column1 = 'X' AND Column2 = 'Y' 

But index1 may well perform better for the second query as it can seek on the two columns directly (as opposed to only being able to search on Column1 then needing to evaluate all matching rows at the index leaf level to see if they meet the Column2 predicate). If Column2 is never used as a search predicate against that index and your queries against that index wouldn't benefit from having Column2 ordered then it should be added as an INCLUDE-d column to keep the size of the key down and reduce the number of pages in the index.

(*) The reason I say "might not" above is because if Column2 is (part of) the clustered index key it will still be added there anyway for a non clustered index not created with the UNIQUE option.

like image 161
Martin Smith Avatar answered Sep 27 '22 21:09

Martin Smith