Antes de trabalhar no Stack Overflow, eu era contra
NOLOCK no principal que você poderia executar um SELECT com NOLOCK e obter resultados com dados que podem estar desatualizados ou inconsistentes. Um fator a se pensar é quantos registros podem ser inseridos/atualizados ao mesmo tempo em que outro processo pode estar selecionando dados da mesma tabela. Se isso acontecer muito, há uma alta probabilidade de deadlocks, a menos que você use um modo de banco de dados como READ COMMITED SNAPSHOT . Desde então, mudei minha perspectiva sobre o uso de
NOLOCK depois de testemunhar como ele pode melhorar SELECT desempenho, bem como eliminar impasses em um SQL Server carregado massivamente. Há momentos em que você pode não se importar se seus dados não estão exatamente 100% comprometidos e você precisa de resultados de volta rapidamente, mesmo que estejam desatualizados. Faça a si mesmo uma pergunta ao pensar em usar
NOLOCK :
Minha consulta inclui uma tabela com um número alto deINSERT/UPDATEcomandos e eu me importo se os dados retornados de uma consulta podem estar faltando essas alterações em um determinado momento?
Se a resposta for não, use
NOLOCK para melhorar o desempenho. Acabei de fazer uma busca rápida pelo
NOLOCK palavra-chave na base de código do Stack Overflow e encontramos 138 instâncias, então a usamos em alguns lugares. 
