SQL Server Reference Guide

Forming Queries Part 5: Table Optimization Hints

Last updated Apr 18, 2008.

Have you ever wondered exactly how SQL Server "answers" a query? By that I mean the process that the SQL Server engine uses to get the data or perform the command you've typed in.

In other articles I've explained how you can use tools such as SQL Server Profiler and the graphical and textual Showplan to watch the steps that SQL Server takes to work with data and data structures. But the fact that there is an engine within SQL Server that processes your commands and requests is only part of the story.

It wouldn't be too difficult to write a program that takes input, stores it, and retrieves or alters it. If you've ever written any code at all, you've probably written a program that does something similar to what a database does. So simply taking in some data and retrieving it again, isn't the magic that an enterprise-scale system provides. The real power and value of a database system is a mechanism that performs these tasks quickly. In SQL Server, that mechanism is the Optimizer.

The Optimizer intercepts all calls to the SQL Server engine and determines the best way to get to the data or implement the command. It does this by using a number of metrics and measurements and adding them up into a "cost". The Optimizer works far quicker than any human could, and it contains more logic and cost information that you or I could calculate. What that means is that in almost every case, the Optimizer will pick the "right" thing to do.

Almost every case. Sometimes you evaluate a Showplan output, and you just can't figure out why a certain index isn't being used, or you think that a particular path to the data might make more sense.

Before we start, it's important to understand that before you force a query with a hint, you should tell yourself that you're probably wrong. You should almost never put these hints on, and if you do, you should understand what the implications are. The Optimizer can see more activity on the server than you can, so it might make one query suffer to enhance the overall performance of the system. Also, if you do put these hints in your code, make sure you note that change and review it after each system change or service pack installation. As things change, the performance of the statements may change. If you're doing performance tuning on a system, these hints are prime places to evaluate for problems.

Note also that even with the Hint, the Optimizer might choose another path. For instance, you might set a certain index to be used, but the Optimizer might find that using it would be a real problem.

Types of Hints

Technically, all of the hints I'll explain in this tutorial are called "Optimizer Hints". The reason is that the Optimizer is what is affected by the Hint, regardless of what object it acts on. There are other types of hints, such as Query Hints, which I'll cover later.

Table/Lock Hints

I've actually covered a few of these Hints already, although not all of them, in another tutorial. I'll cover these first since I think that these are the most useful — something you'll have the best luck with.

Table hints, and specifically lock hints, affect the most common Data Manipulation Language statements, including SELECT, INSERT, UPDATE and DELETE. As I did with the locking hints, let's cover a few of the table hints.

Again, you'll use these in the statements I mentioned above. As an example, let's take a look at a sample SELECT query that you want to force a certain index on:

SELECT Fname 
FROM Customers
WITH (INDEX(FirstNames_idx))

That query, from a fictional table called Customers, would return the FName field. But the key is the bottom part, where the code tells the Optimizer to use an index called FirstNames_idx.

So with that in mind, let's take a look at a few of the ones that I've found useful. First, here's the full list of Table Hints from Books Online:

To narrow the list a bit, let's start with the locking hints I mentioned in the previous article.

READUNCOMMITTED

This hint sets an "isolation level", which has to do with locking. When you set this hint in your query, you can actually read rows that have been changed in another query, but have not yet been committed to the database.

READCOMMITTED

The opposite of the one we just saw — and the default for SQL Server queries. It means that if the data hasn't been written to the database yet, you won't be able to read it until it is.

REPEATABLEREAD

Blocks reads and writes of uncommitted data.

SNAPSHOT

Similar to READUNCOMMITTED, it allows "dirty reads". It's actually even a little more "dirty". You'll have to enable the database option of ALLOW_SNAPSHOT_ISOLATION to use it.

SERIALIZABLE

This hint combines SNAPSHOT and READCOMMITTED, which has the effect of making the data "stable" through the whole query. The downside is that it takes a lot of locks.

Now let's take a look at a few of the other interesting hints. These may have indirect effects on locks, but not as much as the hints we just talked about.

INDEX (indexname, indexname, indexname,...)

This is the hint I pointed out earlier. It asks the optimizer to consider a certain index on a table. While this can be useful, I've found it to be one of the most over-used hints out there. Again, you normally can't out-guess the optimizer!

IGNORE_CONSTRAINTS/IGNORE_TRIGGERS

I mention this hint not because you want to use it, but because you probably won't. From the name, you might think that this helps you because you could insert data and ignore primary and foreign keys, or triggers — and that's partly true. But in reality, you can only use this hint when you're doing a Bulk Insert using the OPENROWSET option, and even so you'll have to deal with these issues later.

KEEPIDENTITY

This hint is one I have used. It has to do with an Identity field, which is a field that is automatically assigned a sequential number by SQL Server. Sometimes, to maintain referential integrity, I need to bring data from one table that has an Identity field to another table that also has the Identity field turned on, often in another database.

What this hint does is allow you to "suspend" the Identity function during and import, keeping the old value (the original from the source table) instead of using the new one from the destination table to be used. You do need to make sure they won't clash, but at least you can keep the old numbers.

Once again, during your INSERT statement you need to have the BULK option used with the OPENROWSET function to make this work.

So there you have it. A series of hints that you can use to help you make things happen on the server the way you want them to. I'll state it once again – you probably don't want to use any of these hints, unless you've taken the time to understand the effects they have on your system. If you do use them, create documentation that states why and where, and then review them constantly, especially after a Service Pack or upgrade.

InformIT Articles and Sample Chapters

Although I've got a great performance tuning section in the database guide, you should also check out this free book excerpt.

Books and eBooks

If you want a full reference on SQL Performance Tuning, check out this book.

Online Resources

Always one of my favorites, the SQL Server Performance Tuning articles here also cover the optimizer.