Efeito da dica NOLOCK nas instruções SELECT

Eu acho que a verdadeira questão é:

Se eu não me importo com leituras sujas, adicionar a dica with (NOLOCK) a uma instrução SELECT afetará o desempenho de:

1. a instrução SELECT atual
2. outras transações contra a tabela especificada

Exemplo:

Select * 
from aTable with (NOLOCK)

1) Sim , selecione comNOLOCK será concluída mais rapidamente que uma seleção normal.

2) Sim , uma seleção com NOLOCKpermitirá que outras consultas na tabela efetuada sejam concluídas mais rapidamente do que uma seleção normal.

Por que isso seria?

NOLOCKnormalmente (dependendo do mecanismo do banco de dados) significa me fornecer seus dados, e eu não me importo em que estado eles estão, e não me importo em mantê-los imóveis enquanto você os lê. É tudo ao mesmo tempo mais rápido, menos intensivo em recursos e muito, muito perigoso.

Você deve ser avisado para nunca fazer uma atualização ou executar algo crítico no sistema, ou onde a correção absoluta seja necessária usando dados originados de uma NOLOCKleitura. É absolutamente possível que esses dados contenham linhas que foram excluídas durante a execução da consulta ou que foram excluídas em outras sessões que ainda não foram finalizadas. É possível que esses dados incluam linhas que foram parcialmente atualizadas. É possível que esses dados contenham registros que violem restrições de chave estrangeira. É possível que esses dados excluam linhas que foram adicionadas à tabela, mas ainda não foram confirmadas.

Você realmente não tem como saber qual é o estado dos dados.

Se você está tentando obter coisas como uma contagem de linhas ou outros dados de resumo onde alguma margem de erro é aceitável, NOLOCKé uma boa maneira de aumentar o desempenho dessas consultas e evitar que elas afetem negativamente o desempenho do banco de dados.

Sempre use a NOLOCKdica com muito cuidado e trate os dados que eles retornam com suspeita.

NOLOCK torna a maioria das instruções SELECT mais rápidas, devido à falta de bloqueios compartilhados. Além disso, a falta de emissão dos bloqueios significa que os gravadores não serão impedidos pelo seu SELECT.

NOLOCK é funcionalmente equivalente a um nível de isolamento de READ UNCOMMITTED. A principal diferença é que você pode usar o NOLOCK em algumas tabelas, mas não em outras, se desejar. Se você planeja usar NOLOCK em todas as tabelas em uma consulta complexa, é mais fácil usar SET TRANSACTION ISOLATION LEAD UNCOMMITTED, porque você não precisa aplicar a dica a todas as tabelas.

Aqui estão informações sobre todos os níveis de isolamento à sua disposição, bem como dicas de tabela.

DEFINIR O NÍVEL DE ISOLAMENTO DA TRANSAÇÃO

Dica de tabela (Transact-SQL)

Além do que foi dito acima, você deve estar ciente de que o nolock realmente impõe o risco de você não obter linhas que foram confirmadas antes sua seleção.

Consulte http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspx

Vai ser mais rápido porque não precisa esperar pelos bloqueios

• A resposta é Sim se a consulta for executada várias vezes ao mesmo tempo, porque cada transação não precisará aguardar a conclusão das outras. No entanto, se a consulta for executada uma vez por si só, a resposta será Não.

• Sim . Existe uma probabilidade significativa de que o uso cuidadoso do WITH (NOLOCK) acelere o banco de dados em geral. Isso significa que outras transações não precisarão esperar a conclusão dessa instrução SELECT, mas, por outro lado, outras transações ficarão mais lentas, pois agora eles estão compartilhando seu tempo de processamento com uma nova transação.

Cuidado para usar apenasWITH (NOLOCK) instruções SELECT em tabelas que possuem um índice em cluster.

WITH (NOLOCK) é frequentemente explorado como uma maneira mágica de acelerar transações de leitura de banco de dados.

O conjunto de resultados pode conter linhas que ainda não foram confirmadas, que geralmente são revertidas posteriormente.

Se WITH (NOLOCK) for aplicado a uma tabela que possui um índice não clusterizado, os índices de linha poderão ser alterados por outras transações, à medida que os dados da linha estiverem sendo transmitidos para a tabela de resultados. Isso significa que o conjunto de resultados pode estar faltando linhas ou exibir a mesma linha várias vezes.

READ COMMITTED adiciona um problema adicional em que os dados são corrompidos em uma única coluna em que vários usuários alteram a mesma célula simultaneamente.