30 March,2016 by Tom Collins
SQL Forceseek table hint was added in SQL Server 2008 , but it was until recently I had a legitimate use for it. I was in the midst of a large data archiving job and the runtimes were slower than expected. Checking the execution plans there were some mysterious index scans.
I was confused. It was a highly selective field , so I expected the index seek to occur. I doublechecked the sql statistics were updated and cleared the cache . I would have expected SQL Server to guess during the runtime and generate an index seek, but this was not occurring.
After a while I realised the issue. The parameter was being passed through as a variable. SQL Server wasn’t able to parameter sniff. OK , no be big deal as I was able to use FORCESEEK , this cleared my problem, and the runtime improved massively.
The FORCESEEK hint constrains the query optimizer to use only an index seek for definining the access path to the data. Here are some examples.
use [master] go select * from sys.sysobjects WITH (FORCESEEK) where name = 'spt_monitor' select name from sys.sysobjects WITH (FORCESEEK,INDEX(IX_xxxxx)) where name = 'spt_monitor'
Although FORCESEEK helped me out in these set of circumstances , I can see it has potential to be abused. My usage was for an adhoc one-off data archive process.
Disadvantages of using FORCESEEK
SQL Server Performance Checklist
SQL Server Performance Killers
This is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
Posted by: |