SQL Server Execution Plans - Red Gate Software

Chapter 5: Controlling Execution Plans with Hints
It's using the clustered index for both queries now because the optimizer is not sure
which of the values available in the table is most likely going to be passed in as @City.
That means it samples the values in the statistics and chooses a generic plan based on an
average value, from the sampled data.
Let's make one more modification. In the second query, we instruct the optimizer to
optimize for 'Mentor'.
DECLARE @City NVARCHAR(30)
SET @City = 'London'
SELECT *
FROM Person.Address
WHERE City = @City
SET @City = 'London'
SELECT *
FROM Person.Address
WHERE City = @City
OPTION ( OPTIMIZE FOR ( @City = 'Mentor' ) );
Listing 5.23
The value 'London' has a very low level of selectivity within the index (i.e. there are a lot
of values equal to 'London'), and this is displayed by the Clustered Index Scan in the first
query. Despite the fact that the second query looks up the same value, it's now the faster
of the two queries for values other than those of 'London'. The OPTIMIZE FOR query
hint was able to trick the optimizer into creating a plan that assumed that the data was
highly selective, even though it was not. The execution plan created was one for the more
selective value 'Mentor' and helps that execution, but hurts that of 'London'.
Use of this hint requires intimate knowledge of the underlying data. Choosing the wrong
value for OPTIMIZE FOR will not only fail to help performance, but could have a very
serious negative impact. You could supply the hint for a value that doesn't represent the
most frequently referenced data set, which would mean you've hurt performance instead
of helping.
203