I Want To Create Index In SQL Server 2008 R2 in Column1 and Column2 What is the difference of below query:
Not include
CREATE NONCLUSTERED INDEX [IX_1] ON [dbo].[MyTable]
(
[Column1] ASC,
[Column2] ASC
) ON [PRIMARY]
Or include:
CREATE NONCLUSTERED INDEX [IX_2] ON [dbo].[MyTable]
(
[Column1] ASC
)
INCLUDE ([Column2]) ON [PRIMARY]
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).
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With