Indexes in SQL Server are created on columns in tables or views. The
index provides a faster way to look up data based on the values in those
columns. For example, if you create an index on the primary key and then search for a
row of data based on one of the primary key values, SQL
Server first finds that value in the index, and then uses the index to
quickly locate the entire row of data. Without the index, a table scan would
have to be performed in order to locate the row, which can have a significant
effect on performance.
An index is made up of a set of pages (index nodes) that are organized in a B-tree structure. This structure is hierarchical in nature, with the root node at the top of the hierarchy and the leaf nodes at the bottom
When a query is issued against an indexed column, the query engine starts at the root node and navigates down through the intermediate nodes, with each layer of the intermediate level more granular than the one above. The query engine continues down through the index nodes until it reaches the leaf node.
For example, if you’re searching for the value 123 in an indexed column, the query engine would first look in the root level to determine which page to reference in the top intermediate level. In this example, the first page points the values 1-100, and the second page, the values 101-200, so the query engine would go to the second page on that level. The query engine would then determine that it must go to the third page at the next intermediate level. From there, the query engine would navigate to the leaf node for value 123. The leaf node will contain either the entire row of data or a pointer to that row, depending on whether the index is clustered or nonclustered.
Indexes in SQL Server 2012:
Clustered
Non-clustered
Covering
Filtered
Columnstore
Clustered Indexes:
A clustered index can be compared to a dictionary, where data is stored in a sorted form. If the data is in sorted form, then you can search for any word very quickly. So essentially A clustered index is table itself in a sorted order based on some column(s).
A clustered index stores the actual data rows at the leaf level of the index.An important characteristic of the clustered index is that the indexed values are sorted in either ascending or descending order. As a result, there can be only one clustered index on a table or view.A table that has no clustered index is referred to as a heap.
Nonclustered Indexes:
You can compare nonclusted index with the index pages given at the end of each book. They actually don't store the data, but point you to the place where the actual data is. You can have multiple non clustered indexes on a table. And of course, the more Non clustered indexes you create on a table, the more storage they take.
Unlike a clustered indexed, the leaf nodes of a nonclustered index contain only pointers to the actual data rows, rather than contain the data rows themselves. A row locator’s structure depends on whether it points to a clustered table or to a heap. If referencing a clustered table, the row locator points to the clustered index, using the value from the clustered index to navigate to the correct data row. If referencing a heap, the row locator points to the actual data row.
Covering Index:
A non-clustered index that contains all the information needed to satisfy a query is known as a covering index.They enable the database administrator to add information to the non-clustered index data pages and avoid having to look up the row in the clustered index.
An index can contain more than one column, as long as the index doesn’t exceed the 900-byte limit in a clustered index key and 1700 bytes for nonclustered index key (In sql 2016).
--Example showing 900 bytes limit
create table IndexLimit(Empid int, EmpDesc varchar(1000))
create clustered index idx on IndexLimit(Empid,EmpDesc)
--Insert Fails
insert into IndexLimit values(12,replicate('a',1000))
--Insert Succeeds
insert into IndexLimit values(12,replicate('a',896))
As beneficial as indexes can be, they must be designed carefully. Because they can take up significant disk space, you don’t want to implement more indexes than necessary. In addition, indexes are automatically updated when the data rows themselves are updated, which can lead to additional overhead and can affect performance.
You should consider the following guidelines when planning your indexing strategy:
For tables that are heavily updated, use as few columns as possible in the index, and don’t over-index the tables.
If a table contains a lot of data but data modifications are low, use as many indexes as necessary to improve query performance. However,use indexes judiciously on small tables because the query engine might take longer to navigate the index than to perform a table scan.
For clustered indexes, try to keep the length of the indexed columns as short as possible. Ideally, try to implement your clustered indexes on unique columns that do not permit null values. This is why the primary key is often used for the table’s clustered index, although query considerations should also be taken into account when determining which columns should participate in the clustered index.
The uniqueness of values in a column affects index performance. In general, the more duplicate values you have in a column, the more poorly the index performs. On the other hand, the more unique each value, the better the performance. When possible, implement unique indexes.
For composite indexes, take into consideration the order of the columns in the index definition. Columns that will be used in comparison expressions in the WHERE clause (such as WHERE FirstName = ‘Charlie’) should be listed first. Subsequent columns should be listed based on the uniqueness of their values, with the most unique listed first.
An index is made up of a set of pages (index nodes) that are organized in a B-tree structure. This structure is hierarchical in nature, with the root node at the top of the hierarchy and the leaf nodes at the bottom
When a query is issued against an indexed column, the query engine starts at the root node and navigates down through the intermediate nodes, with each layer of the intermediate level more granular than the one above. The query engine continues down through the index nodes until it reaches the leaf node.
For example, if you’re searching for the value 123 in an indexed column, the query engine would first look in the root level to determine which page to reference in the top intermediate level. In this example, the first page points the values 1-100, and the second page, the values 101-200, so the query engine would go to the second page on that level. The query engine would then determine that it must go to the third page at the next intermediate level. From there, the query engine would navigate to the leaf node for value 123. The leaf node will contain either the entire row of data or a pointer to that row, depending on whether the index is clustered or nonclustered.
Indexes in SQL Server 2012:
Clustered
Non-clustered
Covering
Filtered
Columnstore
Clustered Indexes:
A clustered index can be compared to a dictionary, where data is stored in a sorted form. If the data is in sorted form, then you can search for any word very quickly. So essentially A clustered index is table itself in a sorted order based on some column(s).
A clustered index stores the actual data rows at the leaf level of the index.An important characteristic of the clustered index is that the indexed values are sorted in either ascending or descending order. As a result, there can be only one clustered index on a table or view.A table that has no clustered index is referred to as a heap.
Nonclustered Indexes:
You can compare nonclusted index with the index pages given at the end of each book. They actually don't store the data, but point you to the place where the actual data is. You can have multiple non clustered indexes on a table. And of course, the more Non clustered indexes you create on a table, the more storage they take.
Unlike a clustered indexed, the leaf nodes of a nonclustered index contain only pointers to the actual data rows, rather than contain the data rows themselves. A row locator’s structure depends on whether it points to a clustered table or to a heap. If referencing a clustered table, the row locator points to the clustered index, using the value from the clustered index to navigate to the correct data row. If referencing a heap, the row locator points to the actual data row.
Covering Index:
A non-clustered index that contains all the information needed to satisfy a query is known as a covering index.They enable the database administrator to add information to the non-clustered index data pages and avoid having to look up the row in the clustered index.
An index can contain more than one column, as long as the index doesn’t exceed the 900-byte limit in a clustered index key and 1700 bytes for nonclustered index key (In sql 2016).
--Example showing 900 bytes limit
create table IndexLimit(Empid int, EmpDesc varchar(1000))
create clustered index idx on IndexLimit(Empid,EmpDesc)
--Insert Fails
insert into IndexLimit values(12,replicate('a',1000))
--Insert Succeeds
insert into IndexLimit values(12,replicate('a',896))
As beneficial as indexes can be, they must be designed carefully. Because they can take up significant disk space, you don’t want to implement more indexes than necessary. In addition, indexes are automatically updated when the data rows themselves are updated, which can lead to additional overhead and can affect performance.
You should consider the following guidelines when planning your indexing strategy:
For tables that are heavily updated, use as few columns as possible in the index, and don’t over-index the tables.
If a table contains a lot of data but data modifications are low, use as many indexes as necessary to improve query performance. However,use indexes judiciously on small tables because the query engine might take longer to navigate the index than to perform a table scan.
For clustered indexes, try to keep the length of the indexed columns as short as possible. Ideally, try to implement your clustered indexes on unique columns that do not permit null values. This is why the primary key is often used for the table’s clustered index, although query considerations should also be taken into account when determining which columns should participate in the clustered index.
The uniqueness of values in a column affects index performance. In general, the more duplicate values you have in a column, the more poorly the index performs. On the other hand, the more unique each value, the better the performance. When possible, implement unique indexes.
For composite indexes, take into consideration the order of the columns in the index definition. Columns that will be used in comparison expressions in the WHERE clause (such as WHERE FirstName = ‘Charlie’) should be listed first. Subsequent columns should be listed based on the uniqueness of their values, with the most unique listed first.
