Counter of Festivals

Ashok Blog for SQL Learners and Beginners and Experts

Tuesday, 17 March 2015

Clustered and Nonclustered Indexes Explanation

Clustered and Nonclustered Indexes

index is an on-disk structure associated with a table or view that speeds retrieval of rows from the table or view. An index contains keys built from one or more columns in the table or view. These keys are stored in a structure (B-tree) that enables SQL Server to find the row or rows associated with the key values quickly and efficiently.
A table or view can contain the following types of indexes:
  • Clustered
    • Clustered indexes sort and store the data rows in the table or view based on their key values. These are the columns included in the index definition. There can be only one clustered index per table, because the data rows themselves can be sorted in only one order.
    • The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. When a table has a clustered index, the table is called a clustered table. If a table has no clustered index, its data rows are stored in an unordered structure called a heap.
  • Nonclustered
    • Nonclustered indexes have a structure separate from the data rows. A nonclustered index contains the nonclustered index key values and each key value entry has a pointer to the data row that contains the key value.
  Non Index Key Value (Pointer)--------------------->> Data Row------------->Key Value
    • The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. For a heap, a row locator is a pointer to the row. For a clustered table, the row locator is the clustered index key.
    • You can add nonkey columns to the leaf level of the nonclustered index to by-pass existing index key limits, 900 bytes and 16 key columns, and execute fully covered, indexed, queries. For more information, see Create Indexes with Included Columns.
Both clustered and nonclustered indexes can be unique. This means no two rows can have the same value for the index key. Otherwise, the index is not unique and multiple rows can share the same key value. For more information, see Create Unique Indexes.
Indexes are automatically maintained for a table or view whenever the table data is modified.

What is the maximum number of Index per table? 
For SQL Server 2005:
1 Clustered Index + 249 Nonclustered Index = 250 Index
http://msdn.microsoft.com/en-us/library/ms143432(SQL.90).aspx
For SQL Server 2008:
1 Clustered Index + 999 Nonclustered Index = 1000 Index
http://msdn.microsoft.com/en-us/library/ms143432.aspx

Limitations and Restrictions 


You can create a clustered index on a column other than primary key column if a nonclustered primary key constraint was specified.

  • The index key of a clustered index cannot contain varchar columns that have existing data in the ROW_OVERFLOW_DATA allocation unit. If a clustered index is created on a varchar column and the existing data is in the IN_ROW_DATA allocation unit, subsequent insert or update actions on the column that would push the data off-row will fail. To obtain information about tables that might contain row-overflow data, use the sys.dm_db_index_physical_stats (Transact-SQL) dynamic management function.




  • If a clustered index is created on a heap with several existing nonclustered indexes, all the nonclustered indexes must be rebuilt so that they contain the clustering key value instead of the row identifier (RID). Similarly, if a clustered index is dropped on a table that has several nonclustered indexes, the nonclustered indexes are all rebuilt as part of the DROP operation. This may take significant time on large tables.
    The preferred way to build indexes on large tables is to start with the clustered index and then build any nonclustered indexes. Consider setting the ONLINE option to ON when you create indexes on existing tables. When set to ON, long-term table locks are not held. This enables queries or updates to the underlying table to continue. 
  • When a clustered index structure is created, disk space for both the old (source) and new (target) structures is required in their respective files and filegroups. The old structure is not deallocated until the complete transaction commits. Additional temporary disk space for sorting may also be required.

How Indexes Are Used by the Query Optimizer


Well-designed indexes can reduce disk I/O operations and consume fewer system resources therefore improving query performance. Indexes can be helpful for a variety of queries that contain SELECT, UPDATE, DELETE, or MERGE statements. Consider the query SELECT Title, HireDate FROM HumanResources.Employee WHERE EmployeeID = 250 in the AdventureWorks2012 database. When this query is executed, the query optimizer evaluates each available method for retrieving the data and selects the most efficient method. The method may be a table scan, or may be scanning one or more indexes if they exist.
When performing a table scan, the query optimizer reads all the rows in the table, and extracts the rows that meet the criteria of the query. A table scan generates many disk I/O operations and can be resource intensive. However, a table scan could be the most efficient method if, for example, the result set of the query is a high percentage of rows from the table.
When the query optimizer uses an index, it searches the index key columns, finds the storage location of the rows needed by the query and extracts the matching rows from that location. Generally, searching the index is much faster than searching the table because unlike a table, an index frequently contains very few columns per row and the rows are in sorted order.
The query optimizer typically selects the most efficient method when executing queries. However, if no indexes are available, the query optimizer must use a table scan. Your task is to design and create indexes that are best suited to your environment so that the query optimizer has a selection of efficient indexes from which to select. SQL Server provides the Database Engine Tuning Advisor to help with the analysis of your database environment and in the selection of appropriate indexes.
Ref:
https://msdn.microsoft.com/en-IN/library/ms190457.aspx

https://msdn.microsoft.com/en-us/library/ms143432(SQL.90).aspx

when you click above link see below this for more info:

Maximum Capacity Specifications for SQL Server 2005:

SQL Server 2005 Database Engine objectMaximum sizes/numbers SQL Server 2005 (32-bit)Maximum sizes/numbers SQL Server 2005 (64-bit)
Batch size1
65,536 * Network Packet Size
65,536 * Network Packet Size
Bytes per short string column
8,000
8,000
Bytes per GROUP BY, ORDER BY
8,060
8,060
Bytes per index key2
900
900
Bytes per foreign key
900
900
Bytes per primary key
900
900
Bytes per row8
8,060
8,060
Bytes per varchar(max)varbinary(max),xmltext, or image column
2^31-1
2^31-1
Characters per ntext or nvarchar(max)column
2^30-1
2^30-1
Clustered indexes per table
1
1
Columns in GROUP BY, ORDER BY
Limited only by number of bytes
Limited only by number of bytes
Columns or expressions in a GROUP BY WITH CUBE or WITH ROLLUP statement
10
10
Columns per index key7
16
16
Columns per foreign key
16
16
Columns per primary key
16
16
Columns per base table
1,024
1,024
Columns per SELECT statement
4,096
4,096
Columns per INSERT statement
1,024
1,024
Connections per client
Maximum value of configured connections
Maximum value of configured connections
Database size
524,258 terabytes
524,258 terabytes
Databases per instance of SQL Server
32,767
32,767
Filegroups per database
32,767
32,767
Files per database
32,767
32,767
File size (data)
16 terabytes
16 terabytes
File size (log)
2 terabytes
2 terabytes
Foreign key table references per table4
253
253
Identifier length (in characters)
128
128
Instances per computer
50 instances on a stand-alone server for all SQL Server 2005 editions except for Workgroup Edition. Workgroup Edition supports a maximum of 16 instances.
SQL Server 2005 supports 25 instances on a failover cluster.
50 instances on a stand-alone server.
25 instances on a failover cluster.
Length of a string containing SQL statements (batch size)1
65,536 * Network packet size
65,536 * Network packet size
Locks per connection
Maximum locks per server
Maximum locks per server
Locks per instance of SQL Server5
Up to 2,147,483,647
Limited only by memory
Nested stored procedure levels6
32
32
Nested subqueries
32
32
Nested trigger levels
32
32
Nonclustered indexes per table
249
249
Parameters per stored procedure
2,100
2,100
Parameters per user-defined function
2,100
2,100
REFERENCES per table
253
253
Rows per table
Limited by available storage
Limited by available storage
Tables per database3
Limited by number of objects in a database
Limited by number of objects in a database
Partitions per partitioned table or index
1,000
1,000
Statistics on non-indexed columns
2,000
2,000
Tables per SELECT statement
256
256
Triggers per table3
Limited by number of objects in a database
Limited by number of objects in a database
UNIQUE indexes or constraints per table
249 nonclustered and 1 clustered
249 nonclustered and 1 clustered
User connections
32,767
32,767
XML indexes
249
249