Bemærk, at du kan angive nolock på en per tabel basis.
Jeg brugte typisk nolock i komplekse SELECT-forespørgsler, men kun til de små opslagstabeller, der næsten aldrig ændrede sig, og til kun visningsdata. Du kender tabellerne, der viser priserne for det aktuelle halvår, eller opslag af id'er til strenge osv. Ting, der kun ændres ved større opdateringer, hvorefter serverne normalt genstartes rutinemæssigt alligevel.
Dette forbedrede ydeevnen betydeligt, reducerede chancen for dødvande i de travleste tider, og endnu vigtigere var det virkelig bemærkelsesværdigt i de værste tilfælde for forespørgsler, der rørte mange tabeller (hvilket er logisk, de skal opnå færre låse, og disse sideborde bruges ofte næsten overalt, ofte faldende fra 7-8 til 4 borde, der skal låses)
Men vær meget forsigtig med at tilføje det, forhast det ikke, og gør det ikke rutinemæssigt. Det vil ikke gøre ondt, når det bruges korrekt, men det vil gøre frygteligt ondt, når det bruges forkert.
Brug det ikke til meget kritiske ting, ting, der beregner osv., fordi det bliver inkonsekvent, alt, hvad der fører til en skrivning før eller siden.
En anden sådan optimering er ROWLOCK, som kun låser på rækkeniveau. Dette er hovedsageligt nyttigt, når du opdaterer (eller sletter i) tabeller, hvor rækkerne ikke er relateret til hinanden, som tabeller, hvor du kun indsætter log-poster (og rækkefølgen, de er indsat i, betyder ikke noget). Hvis du har en plan om, at et sted i slutningen af en transaktion skrives en logpost til en tabel, kan dette også fremskynde betydeligt.
Hvis din database har en relativt lav procentdel skriverier, er det måske ikke det værd. Jeg havde et læse:skriveforhold på under 2:1.
Nogle URL'er, jeg gemte, da jeg arbejdede med dette:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/