Merk op dat u nolock per tafel kunt specificeren.
Ik gebruikte meestal nolock in complexe SELECT-query's, maar alleen voor de kleine opzoektabellen die bijna nooit veranderden, en voor alleen-weergavegegevens. U kent de tabellen met de prijzen voor het huidige half jaar, of het opzoeken van id's naar strings enz. Dingen die alleen veranderen bij grote updates, waarna de servers meestal toch routinematig opnieuw worden opgestart.
Deze verbeterde prestatie aanzienlijk, verminderde de kans op een deadlock in de drukste tijden, en belangrijker nog, het was echt merkbaar tijdens de worstcasemomenten voor vragen die veel tabellen raakten (wat logisch is, ze hoeven minder vergrendelingen te verkrijgen, en die sidetables worden vaak bijna overal gebruikt, vaak afnemend van 7-8 tot 4 tafels die moeten worden vergrendeld)
Maar wees heel voorzichtig met het toevoegen, overhaast het niet en doe het niet routinematig. Het doet geen pijn als het op de juiste manier wordt gebruikt, maar het zal vreselijk pijn doen als het verkeerd wordt gebruikt.
Gebruik het niet voor zeer kritische dingen, dingen die berekent enz., want het wordt inconsistent, alles wat vroeg of laat tot schrijven leidt.
Een andere dergelijke optimalisatie is ROWLOCK, die alleen op rijniveau vergrendelt. Dit is vooral handig bij het bijwerken (of verwijderen van) tabellen waarin de rijen niet aan elkaar gerelateerd zijn, zoals tabellen waar je alleen logrecords invult (en de volgorde waarin ze worden ingevoegd maakt niet uit). Als je een schema hebt dat ergens aan het einde van een transactie een logrecord naar een tabel wordt geschreven, kan dit ook aanzienlijk versnellen.
Als uw database een relatief laag schrijfpercentage heeft, is het misschien niet de moeite waard. Ik had een lees-schrijfverhouding van minder dan 2:1.
Enkele URL's die ik heb opgeslagen toen ik hieraan werkte:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/