Tieni presente che puoi specificare nolock in base alla tabella.
In genere usavo nolock nelle query SELECT complesse, ma solo per le piccole tabelle di ricerca che non cambiavano quasi mai e per i dati di sola visualizzazione. Conosci le tabelle che elencano i prezzi per il semestre in corso, o le ricerche di ID su stringhe, ecc. Cose che cambiano solo con aggiornamenti importanti, dopodiché i server di solito vengono comunque riavviati regolarmente.
Queste prestazioni migliorate in modo significativo, riducevano la possibilità di deadlock nei periodi di maggiore affluenza e, cosa più importante, era davvero evidente durante i momenti peggiori per le query che toccavano molte tabelle (che è logico, devono ottenere meno blocchi e quei sidetable sono spesso usati quasi ovunque, spesso diminuendo da 7-8 a 4 tavoli che devono essere bloccati)
Ma fai molta attenzione ad aggiungerlo, non avere fretta e non farlo di routine. Non farà male se usato correttamente, ma farà terribilmente male se usato in modo improprio.
Non usarlo per cose altamente critiche, cose che calcolano ecc, perché diventerà incoerente, qualsiasi cosa che prima o poi porti a una scrittura.
Un'altra ottimizzazione di questo tipo è ROWLOCK, che si blocca solo a livello di riga. Ciò è utile principalmente quando si aggiornano (o si eliminano) tabelle in cui le righe non sono correlate tra loro, come le tabelle in cui si inseriscono solo record di registro (e l'ordine in cui sono inseriti non ha importanza). Se hai uno schema per cui da qualche parte alla fine di una transazione un record di registro viene scritto su una tabella, anche questo può accelerare notevolmente.
Se il tuo database ha una percentuale di scritture relativamente bassa potrebbe non valerne la pena. Avevo un rapporto di lettura:scrittura inferiore a 2:1.
Alcuni URL che ho salvato lavorando su questo:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/
