SQL SERVER 2008

124 ❘ CHAPTER 5 QUERY PROCESSING AND EXECUTION
Problems with using hints can happen at any time — from when you start using the hint, which can
cause unexpected side effects that cause the query to fail to compile, to more complex and diffi cult
to fi nd performance issues that occur later.
As data in the relevant tables changes, without query hints the Query Optimizer automatically
updates statistics and adjusts query plans as needed; but if you have locked the Query Optimizer
into a specifi c set of optimizations using query hints, then the plan cannot be changed, and you may
end up with a considerably worse plan, requiring further action (from you) to identify and resolve
the root cause of the new performance issue.
One fi nal word of caution about using query hints: Unlike locking hints (also referred to in BOL
as table hints), which SQL Server attempts to satisfy, query hints are stronger, so if SQL Server is
unable to satisfy a query hint it will raise error 8622 and not create any plan.
Query hints are specifi ed using the OPTION clause, which is always added at the end of the T-SQL
statement — unlike locking or join hints, which are added within the T-SQL statement after the
tables they are to affect.
NOTE Refer to the Transact SQL Reference, Data Manipulation Language,
Hints(Transact-SQL) section, or search for query hints in SQL Server 2012
Books Online for a complete list of query hints.
The following sections describe a few of the more interesting query hints.
FAST number_rows
Use this query hint when you want to retrieve only the fi rst n rows out of a relatively large result set.
A typical example of this is a website that uses paging to display large sets of rows, whereby the fi rst
page shows only the fi rst web page worth of rows, and a page might contain only 20, 30, or maybe
40 rows. If the query returns thousands of rows, then SQL Server would possibly optimize this
query using hash joins. Hash joins work well with large datasets but have a higher setup time than
perhaps a nested loop join. Nested loop joins have a very low setup cost and can return the fi rst
set of rows more quickly but takes considerably longer to return all the rows. Using the
FAST query hint causes the Query Optimizer to use nested loop joins and other
techniques, rather than hashed joins, to get the fi rst n rows faster.
Typically, once the fi rst n rows are returned, if the remaining rows are retrieved, the query performs
slower than if this hint were not used.
{Loop | Merge | Hash } JOIN
The JOIN query hint applies to all joins within the query. While this is similar to the join hint that
can be specifi ed for an individual join between a pair of tables within a large more complex query,
the query hint applies to all joins within the query, whereas the join hint applies only to the pair of
tables in the join with which it is associated.