Indexes By Adrienne Watt

What is an Index An index is a table structure that SQL Server uses to provide fast access to rows of a table based on the values of one or more columns. An index contains data values and pointers to the rows where those values occur.

What is an Index The employee table in the pubs database has an index on the employee ID (emp_id) column

Choose Indexes Determine whether adding indexes will improve the performance of the system. One approach is to keep rows unordered and create as many secondary indexes as necessary. Secondary indexes- actual data is not sorted by index Primary indexes- index on primary key Clustered indexes- actual data is sorted on index When no indexes are available, SQL Server must perform a table scan, reading every data page in the table. When an index is available, and the optimizer determines that using that index will result in fewer logical and physical page I/Os than a table scan, it will use that index.

Choose Indexes A clustered index is one in which the logical (indexed) order of the key values is the same as the physical order in which the corresponding rows (that contain the key values) exist in the table.

Candidates for Clustered Indexes Columns that will not be frequently updated Foreign keys, because they are generally nonunique Columns where data will be accessed in sequence by a range of values Columns that include a lot of duplicate values Columns that will be used with the GROUP BY or ORDER BY clauses Columns used in joins, such as foreign key columns

Choose Indexes A nonclustered index is one in which the logical order of the index does not match the physical order of the rows on disk. If ordering attribute chosen is key of relation, index will be a primary index; otherwise, index will be a clustering index. Each relation can only have either a primary index or a clustering index and multiple secondary indexes. Secondary indexes provide a mechanism for specifying an additional key for a base relation that can be used to retrieve data more efficiently.

Choose Indexes Overhead involved in maintenance and use of secondary indexes that has to be balanced against performance improvement gained when retrieving data. This includes: adding an index record to every secondary index whenever row is inserted; updating a secondary index when corresponding row is updated; increase in disk space needed to store the secondary index; possible performance degradation during query optimization to consider all secondary indexes.

Choose Indexes – Guidelines for Choosing ‘Wish-List’ (1) Do not index small relations. (2) Index PK of a relation if it is not a key of the file organization. (3) Add secondary index to a FK if it is frequently accessed. (4) Add secondary index to any attribute that is heavily used as a secondary key. (5) Add secondary index on attributes that are involved in: selection or join criteria; ORDER BY; GROUP BY; and other operations involving sorting (such as UNION or DISTINCT).

Choose Indexes – Guidelines for Choosing ‘Wish-List’ (6) Add secondary index on attributes involved in built-in functions. (7) Add secondary index on attributes that could result in an index-only plan. (8) Avoid indexing an attribute or relation that is frequently updated. (9) Avoid indexing an attribute if the query will retrieve a significant proportion of the tuples in the relation. (10) Avoid indexing attributes that consist of long character strings.

Planning your queries Use the WHERE clause to restrict the number of rows that must be processed to execute a query. Unless absolutely necessary, avoid unrestricted queries that must read and process all the rows of a table. For example, the following restricted query: SELECT qty FROM sales WHERE stor_id = 7131 is more efficient than the following unrestricted query: 

Planning your queries Avoid returning a large results set to the client for final data selection through browsing. Restrict the size of the results set reduces network I/O and improves concurrency-related performance as the application scales upward to more users.  Because the WHERE clause of a query is the primary focus of the optimizer, use queries that can take advantage of a useful index. Each index on the table includes columns that are possible candidates for including in the WHERE clause.

Planning your queries For optimal performance consider a query with a WHERE clause that includes column1. A single-column index on column1 A multicolumn index where column1 is the first column of the index SELECT au_id, au_lname, au_fname FROM authors WHERE au_lname = 'White‘ AND au_fname = 'Johnson'   WHERE au_lname = 'White' the following query would not be able to use the index: WHERE au_fname = 'Johnson'

Index creating Create clustered index ndxName on tblCustomer(country, city) Create index ndxName on tblGuest(guest_no) Drop index ndxname