Observera att du kan ange nolock per tabell.
Jag använde vanligtvis nolock i komplexa SELECT-frågor, men bara för de små uppslagstabellerna som nästan aldrig ändrades, och för endast visningsdata. Du vet tabellerna som listar priserna för det aktuella halvåret, eller uppslagningar av id till strängar etc. Saker som bara ändras med större uppdateringar varefter servrarna vanligtvis startas om rutinmässigt ändå.
Detta förbättrade prestandan avsevärt, minskade risken för dödläge under de mest hektiska tiderna, och ännu viktigare var det verkligen märkbart i värsta fall för frågor som berörde många tabeller (vilket är logiskt, de måste få färre lås, och de sidoborden används ofta nästan överallt, ofta minskande från 7-8 till 4 bord som måste låsas)
Men var mycket försiktig med att lägga till det, skynda inte på det och gör det inte rutinmässigt. Det kommer inte att göra ont när det används på rätt sätt, men det kommer att göra fruktansvärt ont när det används på fel sätt.
Använd det inte för mycket kritiska saker, saker som beräknar etc, eftersom det kommer att bli inkonsekvent, allt som leder till en skrivning förr eller senare.
En annan sådan optimering är ROWLOCK, som bara låser på radnivå. Detta är främst användbart när du uppdaterar (eller tar bort i) tabeller där raderna inte är relaterade till varandra, som tabeller där du bara lägger in loggposter (och ordningen i vilken de infogas spelar ingen roll). Om du har ett schema att någonstans i slutet av en transaktion en loggpost skrivs till någon tabell, kan detta också påskyndas avsevärt.
Om din databas har en relativt låg andel skrivningar kanske det inte är värt det. Jag hade ett läs:skrivförhållande på under 2:1.
Några webbadresser som jag sparade när jag arbetade med detta:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/