Observe que você pode especificar nolock por tabela.

Eu normalmente usava nolock em consultas SELECT complexas, mas apenas para as pequenas tabelas de pesquisa que quase nunca mudavam e para dados somente de exibição. Você conhece as tabelas que listam os preços para o semestre atual, ou pesquisas de ids para strings etc. Coisas que só mudam com grandes atualizações após as quais os servidores geralmente são reiniciados rotineiramente de qualquer maneira.

Isso melhorou significativamente o desempenho, reduziu a chance de deadlock nos horários mais movimentados e, mais importante, foi realmente perceptível durante os piores momentos para consultas que tocavam muitas tabelas (o que é lógico, elas precisam obter menos bloqueios e essas tabelas laterais são frequentemente usados ​​em quase todos os lugares, muitas vezes diminuindo de 7-8 para 4 mesas que precisam ser bloqueadas)

Mas tenha muito cuidado ao adicioná-lo, não o apresse e não o faça rotineiramente. Não vai doer quando usado corretamente, mas vai doer horrivelmente quando usado de forma inadequada.

Não o use para coisas altamente críticas, coisas que calculam, etc., porque ficará inconsistente, qualquer coisa que leve a uma gravação mais cedo ou mais tarde.

Outra otimização desse tipo é ROWLOCK, que trava apenas no nível da linha. Isso é útil principalmente ao atualizar (ou excluir) tabelas em que as linhas não estão relacionadas umas às outras, como tabelas em que você coloca apenas registros de log (e a ordem em que são inseridas não importa). Se você tiver um esquema em que em algum lugar no final de uma transação um registro de log seja gravado em alguma tabela, isso também pode acelerar consideravelmente.

Se o seu banco de dados tiver uma porcentagem de gravações relativamente baixa, pode não valer a pena. Eu tinha uma relação de leitura:gravação de menos de 2:1.

Alguns URLs que salvei ao trabalhar nisso:

http://www.developerfusion.com/article/1688/ sql-server-locks/4/