Index is a database object which contains an entry of each record that appears in the Indexed column to provide faster access of data. Indexes are used in a View or a Table. Knowing the concept of Index in detail is very crucial to database administrators, database developers, and anyone who likes to work with database. The proper use of Index makes your query and database perform faster. But it might hurt your query performance and add overhead to database if not used properly. With this article, you will walk away with learning the characteristics, Index types, SQL syntax, query consideration, column consideration and the key difference between Clustered and non Clustered Index.
Clustered Index:
An Index that sort and store the data row in the table or view on their key values. You can have one Clustered Index per table as the data rows sort in only one order. A table with Clustered Index sorts the data based on the column where there is Clustered Index. The table with Clustered Indexed is also called Clustered table. A table without a Clustered Index is a heap table because it is not sorted in any order. A Clustered Index is created while creating a Primary Key or can be created later after the table creation.
Properties:
- Sorts and stores data rows in the table.
- One Clustered Index per table
- Every table should have Clustered Index
- Clustered Index is created by default when creating a PK
- Improved query performance
- Rebuild and Reorganized can be performed to avoid table fragmentation.
- View can have Clustered Index
SQL Syntax:
USE adventureworks2012; go -- Create a new table with three columns. CREATE TABLE employee ( empno INT, ename VARCHAR(10), job VARCHAR(9), mgr INT NULL, hiredate DATETIME, sal NUMERIC(7, 2), comm NUMERIC(7, 2) NULL, dept INT ) go -- Create a clustered index called IX_Employee_Empno -- on the dbo.employee table using the empno column. CREATE CLUSTERED INDEX ix_employee_empno ON dbo.employee (empno); go
Primary Key:
CREATE TABLE employee ( empno INT PRIMARY KEY, ename VARCHAR(10), job VARCHAR(9), mgr INT NULL, hiredate DATETIME, sal NUMERIC(7, 2), comm NUMERIC(7, 2) NULL, dept INT )
Index Verify:
USE adventureworks2012;
go
SELECT *
FROM sys.indexes
WHERE object_id = (SELECT object_id
FROM sys.objects
WHERE NAME = 'employee') -- Your table name
Understanding how the table data will be accessed and used in any applications is very crucial while designing a database. This also help us pick the right Index type for a table. You should consider Clustered Index if your queries do the following:
- Returns ranges of values by using Operators such as BETWEEN, >, >=, <, and <=.
- Return large result sets
- Use JOIN clauses
- Use ORDER BY, or GROUP BY clauses. (data already sorted, db engine don't need to sort data which improved the performance )
Detail understanding of data and how the table will be accessed and used in an application will help us to pick the right column for a Clustered Index to maximize the performance. You should consider Clustered Index on a column that has:
- Are UNIQUE or contain more distinct values
- Are accessed sequentially
- Column that is defined as IDENTITY
- Used frequently to sort data retrieved from a table
Clustered Indexed is not a good choice if
- Wide Keys or Composite key with wide column length
- Column that under go frequent changes
Non Clustered Index:
A regular Index which most database systems come with. The non Clustered Index contains key values where each key value entry has a pointer to the data work that contains the key value. You can have multiple non Clustered Index as you are not sorting data on that record like in Clustered Index. When you create a UNIQUE constraint, a unique non-clustered Index is created to enforce a UNIQUE constraint by default. An Index created as part of creating PK or UNIQUE constraint is given the same name as the constraint name. Clustered Index can be created on a column other than a primary key column if a non-clustered primary key constraint was specified.Properties:
- UNIQUE constraints creates non clustered Index by default
- Can have more than 1 but less than 1000 non Clustered Index per table
- Not mandatory for a table
- Improves query performance
- Rebuild and Reorganized can be performed to avoid table fragmentation.
- View can have non-clustered Index
USE adventureworks2012; go -- Create a new table with three columns. CREATE TABLE employee ( empno INT, ename VARCHAR(10), job VARCHAR(9), mgr INT NULL, hiredate DATETIME, sal NUMERIC(7, 2), comm NUMERIC(7, 2) NULL, dept INT ) go -- Create a non clustered index called IX_Employee_Empno -- on the dbo.employee table using the empno column. CREATE NONCLUSTERED INDEX ix_employee_empno ON dbo.employee (empno); go
Unique Constraint:
USE adventureworks2012; go --drop table dbo.employee; -- Create a new table with three columns. CREATE TABLE employee ( empno INT NOT NULL, ename VARCHAR(10), job VARCHAR(9), mgr INT NULL, hiredate DATETIME, sal NUMERIC(7, 2), comm NUMERIC(7, 2) NULL, dept INT CONSTRAINTS AK_employee_cmpno UNIUQE(empno) ) go
Index Verify:
USE adventureworks2012; go SELECT * FROM sys.indexes WHERE object_id = (SELECT object_id FROM sys.objects WHERE NAME = 'employee') -- Your table name
Query Considerations: Understanding how the table data will be accessed and used in any applications is very crucial while designing a database. This also help us pick the right Index type on a table. You should consider non Clustered Index if your queries do the following:
- User JOIN or GROUP BY clauses
- Queries that do not return large result sets.
- Query that has filter conditions like WHERE clause
Congratulations! You have successfully graduated from Index University! Now, It is your time to check your databases to see if any of the tables needed Index. If it does, you now should also able to tell pick the correct Index type for your table. Also, I recommend checking the existing Index to verify if they are designed correctly, it does not hurt to double check as it does not hurt the performance. Using Index inappropriately can kill your database therefore, learn Index, use Index well, and prolong your database health.
Source: https://msdn.microsoft.com/en-us/library/ms190457.aspx
Interested in working with me? I can be reached at pbaniya04[at]gmail.com for any questions, consulting opportunities or you may drop a line to say HELLO. Thank your again for visiting my blog and looking forward to serving you more.
Have a Database-ious Day!
Have a Database-ious Day!
This is very well put and easy to follow. Thanks.
ReplyDelete