Usar con (nolock) para aumentar el rendimiento

Question

He visto desarrolladores usando con (Nolock) en la consulta, ¿hay alguna desventaja de ello? Además, ¿cuál es el modo de ejecución predeterminado de consulta? Mi base de datos no tiene ningún índice.

¿Hay alguna otra forma de aumentar el rendimiento de la declaración de selección de la base de datos?

Answer 1

El error común con Nolock es que no coloca bloqueos en la base de datos mientras se ejecuta. Técnicamente, emite un bloqueo de estabilidad de esquema (SCH-S), por lo que la parte 'no' del bloqueo se relaciona con el lado de los datos de la consulta.

La mayoría de las veces que veo esto, es una optimización prematura de un desarrollador porque han oído que hace que la consulta sea más rápida.

A menos que tenga pruebas y validez instrumentadas al aceptar una lectura sucia (y potencialmente leer la misma fila dos veces), entonces no debe usarse; definitivamente no debería ser el enfoque predeterminado de las consultas, sino una excepción a la regla cuando se puede mostrar que es necesario.

Answer 2

Hay numerosos artículos sobre esto en la red. El riesgo principal es que con NOLOCK Puede leer datos no prometidos de la tabla (lecturas sucias). Ver, por ejemplo, http://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspx o http://www.techrepublic.com/article/using-nolock-and-readpast-table-hints-in-sql-server/6185492

Answer 3

NOLOCK Puede ser muy útil cuando está leyendo datos antiguos de una tabla de uso frecuente. Considere el siguiente ejemplo,

Tiene un procedimiento almacenado para acceder a los datos de proyectos inactivos. No desea que este procedimiento almacenado bloquee la tabla de proyectos de uso frecuente mientras lee datos antiguos.

NOLOCK También es útil cuando las lecturas sucias no son un problema y los datos no se modifican con frecuencia, como en los siguientes casos,

Lista de lectura de países, monedas, etc. de una base de datos para mostrar en el formulario. Aquí los datos permanecen sin cambios y una lectura sucia no causará un gran problema, ya que ocurrirá muy raramente.

Sin embargo, comenzando con SQL Server 2005, los beneficios de Nolock son muy pequeños debido a la versión de fila.