- Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- An Outline for Development
- Database Services
- Database Objects: Databases
- Database Objects: Tables
- Database Objects: Table Relationships
- Database Objects: Keys
- Database Objects: Constraints
- Database Objects: Data Types
- Database Objects: Views
- Database Objects: Stored Procedures
- Database Objects: Indexes
- Database Objects: User Defined Functions
- Database Objects: Triggers
- Database Design: Requirements, Entities, and Attributes
- Business Process Model Notation (BPMN) and the Data Professional
- Business Questions for Database Design, Part One
- Business Questions for Database Design, Part Two
- Database Design: Finalizing Requirements and Defining Relationships
- Database Design: Creating an Entity Relationship Diagram
- Database Design: The Logical ERD
- Database Design: Adjusting The Model
- Database Design: Normalizing the Model
- Creating The Physical Model
- Database Design: Changing Attributes to Columns
- Database Design: Creating The Physical Database
- Database Design Example: Curriculum Vitae
- The SQL Server Sample Databases
- The SQL Server Sample Databases: pubs
- The SQL Server Sample Databases: NorthWind
- The SQL Server Sample Databases: AdventureWorks
- The SQL Server Sample Databases: Adventureworks Derivatives
- UniversalDB: The Demo and Testing Database, Part 1
- UniversalDB: The Demo and Testing Database, Part 2
- UniversalDB: The Demo and Testing Database, Part 3
- UniversalDB: The Demo and Testing Database, Part 4
- Getting Started with Transact-SQL
- Transact-SQL: Data Definition Language (DDL) Basics
- Transact-SQL: Limiting Results
- Transact-SQL: More Operators
- Transact-SQL: Ordering and Aggregating Data
- Transact-SQL: Subqueries
- Transact-SQL: Joins
- Transact-SQL: Complex Joins - Building a View with Multiple JOINs
- Transact-SQL: Inserts, Updates, and Deletes
- An Introduction to the CLR in SQL Server 2005
- Design Elements Part 1: Programming Flow Overview, Code Format and Commenting your Code
- Design Elements Part 2: Controlling SQL's Scope
- Design Elements Part 3: Error Handling
- Design Elements Part 4: Variables
- Design Elements Part 5: Where Does The Code Live?
- Design Elements Part 6: Math Operators and Functions
- Design Elements Part 7: Statistical Functions
- Design Elements Part 8: Summarization Statistical Algorithms
- Design Elements Part 9:Representing Data with Statistical Algorithms
- Design Elements Part 10: Interpreting the Data—Regression
- Design Elements Part 11: String Manipulation
- Design Elements Part 12: Loops
- Design Elements Part 13: Recursion
- Design Elements Part 14: Arrays
- Design Elements Part 15: Event-Driven Programming Vs. Scheduled Processes
- Design Elements Part 16: Event-Driven Programming
- Design Elements Part 17: Program Flow
- Forming Queries Part 1: Design
- Forming Queries Part 2: Query Basics
- Forming Queries Part 3: Query Optimization
- Forming Queries Part 4: SET Options
- Forming Queries Part 5: Table Optimization Hints
- Using SQL Server Templates
- Transact-SQL Unit Testing
- Index Tuning Wizard
- Unicode and SQL Server
- SQL Server Development Tools
- The SQL Server Transact-SQL Debugger
- The Transact-SQL Debugger, Part 2
- Basic Troubleshooting for Transact-SQL Code
- An Introduction to Spatial Data in SQL Server 2008
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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.
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.
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.
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.
Blocks reads and writes of uncommitted data.
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.
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!
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.
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
Books and eBooks
If you want a full reference on SQL Performance Tuning, check out this book.
Always one of my favorites, the SQL Server Performance Tuning articles here also cover the optimizer.