Creating an Index on Our Person Table to Increase Query Performance
This chapter is from the book
This chapter is from the book
This chapter is from the book
We are going to create an index on our Person table to help increase the performance of any queries run against the table. Well, that's not true, really! Because the application is so small at the moment, this exercise will not dramatically increase performance, but it will in the future when we have a lot more data.
Before we start, we are going to execute a query without implementing our index. But this time before we execute the index we are going to use another one of SQL Server 2000's debugging tools, the execution plan.
An execution plan is a graphical representation of how SQL Server 2000 actually executes a query. They are brilliant for debugging complex queries because you can easily see areas that performance costs are the highest.
SQL Server 2000 supports two types of execution plans: estimated execution plans and the actual plans after the query has executed.
The estimated plans are used to analyze the query you have just entered into the Query Analyzer window, to give you an idea of the performance of the query. This can be especially useful for long-running queries to get an idea of how they will perform.
Execution plans delivered after the query has run display the actual results of the execution plan, providing invaluable information when pinpointing poor performance in queries.
Checking a Pre-Index Query with Execution Plan
To turn on the graphical execution plan in Query Analyzer, follow these steps:
-
Choose Query, Show Execution Plan (as shown in Figure 1), or press Ctrl+K.
Figure 1 Where to find the execution plan within Query Analyzer.
After you have selected to view the execution plan, enter the Transact-SQL code in Listing 1 so that we can see our execution plan.
){kind=link}
Listing 1 Executing a SELECT Statement Without Our Index Defined on the Person Table
1: SELECT * FROM Person 2: WHERE Firstname LIKE '%a%'
The results pane of the Query Analyzer window will contain a tab called Execution Plan. If you select that tab, you will see results similar to those shown in Figure 2.
){kind=link}
Figure 2 Showing the results of the query with the execution plan turned on within Query Analyzer using the clustered index defined on the PersonID column.
TIP
If you hold your mouse over the Person.PK_Person image you will see information that shows how SQL Server 2000 performed different operations to bring the results of the query back.
Although a lot of information is returned to us (sometimes a little too much!), what we are really looking at (in this instance, at any rate) is the Physical Operation value. This specifies that the query uses the current clustered index defined on the table (that is, the primary key we have defined on the table).
Although this is fine for the few rows we currently have in our table, when we have hundreds of rows, it may not be a good idea to use the primary key for the query because the WHERE criteria is applied to the Firstname column.
Let's create an index on our Firstname column so when we do have hundreds more rows, the Query Optimizer will use the index to retrieve our data.
Indexing the Person Table
The type of index we will create is a nonclustered index. The main reason we cannot create a clustered index on our table is that it already has a clustered index specified on the table. When we created the primary key PersonID, SQL Server 2000 automatically created a clustered index on the PersonID column, and we are not allowed more than one clustered index on a table.
To create our index, enter the Transact-SQL code in Listing 2 into Query Analyzer.
Listing 2 Creating an Index on Our Person Table to Enhance Future Performance
1: CREATE NONCLUSTERED INDEX idxPersonFirstname 2: ON Person (Firstname)
And there we have it. Our first index! It's simple really, but before we continue, let's just take a quick look at the structure of the statement.
Line 1 specifies the type of index we want to create, in this instance a non-clustered index with the name idxPersonFirstname.
Line 2 specifies the table (Person) and the column (Firstname) that we want the index to be created on.
Checking the Performance Change After Indexing
Let's execute our query again, but this time we will make a little change to the query (see Listing 3).
Listing 3 Executing a SELECT Statement with Our Index Defined on the Person Table Forcing Us to Use the New idxPersonFirstname
1: SELECT * FROM Person 2: WITH (INDEX(idxPersonFirstname)) 3: WHERE Firstname LIKE '%a%'
Line 2 alters our query to force SQL Server 2000 to use our new index. We need to do this because the Query Optimizer will not use our index. There simply is not enough data for the Optimizer to justify using the index.
WARNING
It is not usually classed as good practice to force SQL Server 2000 to use an index to retrieve results. This is the job of the Query Optimizer, which understands the intricacies of the inner workings of SQL Server 2000 far better than we can.
The method I have demonstrated is really just for demonstration purposes only.
Now when you look at the execution plan, as shown in Figure 3, you will see that SQL Server 2000 has used our index to perform the query.
){kind=link}
Figure 3 Showing the query results using the nonclustered index.
Holding your mouse over the Person.idxFirstname icon, you can see that we have forced SQL Server 2000 to perform an index scan to retrieve the data from our table.
We have now created an index and seen how to use one.