Antes de trabajar en Stack Overflow, estaba en contra de NOLOCK en el principio de que potencialmente podría realizar un SELECT con NOLOCK y obtenga resultados con datos que pueden estar desactualizados o ser inconsistentes. Un factor a tener en cuenta es cuántos registros se pueden insertar/actualizar al mismo tiempo, otro proceso puede estar seleccionando datos de la misma tabla. Si esto sucede con frecuencia, existe una alta probabilidad de interbloqueos a menos que utilice un modo de base de datos como READ COMMITED SNAPSHOT .
Desde entonces he cambiado mi perspectiva sobre el uso de NOLOCK después de ver cómo puede mejorar SELECT rendimiento, así como eliminar interbloqueos en un servidor SQL cargado masivamente. Hay momentos en los que puede que no le importe que sus datos no estén exactamente comprometidos al 100 % y necesite resultados rápidamente, aunque estén desactualizados.
Hágase una pregunta cuando piense en usar NOLOCK :
¿Mi consulta incluye una tabla que tiene una gran cantidad de INSERT? /UPDATE ¿Me importa si a los datos devueltos por una consulta les faltan estos cambios en un momento dado?
Si la respuesta es no, utilice NOLOCK para mejorar el rendimiento.
NOLOCK palabra clave dentro del código base para Stack Overflow y encontró 138 instancias, por lo que la usamos en bastantes lugares. 
