outro dia, durante o SQL Server Performance Tuning Seminário Prático, eu entrei em uma situação muito interessante. Ao sintonizar uma consulta tivemos uma situação quando tivemos que verificar se a consulta está bloqueada durante a execução de não., Para testar a nossa teoria tivemos que colocar uma dica de nolock para cada tabela da consulta longa. No entanto, não foi possível fazê-lo, uma vez que o procedimento armazenado era super enorme e envolvia mais de 90 tabelas e 14 Visualizações em múltiplas declarações SQL. Foi realmente um grande desafio para uma equipe de desenvolvedores para modificar esse SP. Se alguma vez enfrentares tais situações, não te deves stressar. Há uma maneira muito mais simples de ler dados não enviados.,
Antes de continuar a ler este post no blog, por favor note que eu, pessoalmente, não prefiro usar as dicas de NOLOCK no meu negócio, uma vez que ele irá ler os dados sujos e muitas vezes a leitura de dados não autorizados cria problemas com a integridade da base de dados. Existem muitas maneiras diferentes de sintonizar a sua consulta em vez de usar a dica NOLOCK ou usar o isolamento da transacção sem compromisso de leitura.
vamos ver primeiro um exemplo simples de como a dica NOLOCK funciona com várias tabelas.,
agora vamos converter o mesmo script para usar o isolamento de transação sem compromisso de leitura.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDGOSELECT *FROM . ctINNER JOIN . spON ct.StateProvinceID = sp.StateProvinceIDGOSET TRANSACTION ISOLATION LEVEL READ COMMITTEDGO
Tecnicamente, não há absolutamente nenhuma diferença entre o desempenho e o impacto de ambos os métodos. Eu prefiro usar o segundo método mais frequentemente como é mais fácil de escrever e testar. Mais uma vez, se possível, eu gosto de ficar longe de ler métodos não comprometidos para ler os dados.
