Tenga en cuenta que puede especificar nolock por tabla.
Por lo general, usaba nolock en consultas SELECT complejas, pero solo para las pequeñas tablas de búsqueda que casi nunca cambiaban y para datos de solo visualización. Conoce las tablas que enumeran los precios para el semestre actual, o las búsquedas de identificadores de cadenas, etc. Cosas que solo cambian con actualizaciones importantes, después de lo cual los servidores generalmente se reinician de forma rutinaria de todos modos.
Esto mejoró significativamente el rendimiento, redujo la posibilidad de interbloqueo en los momentos de mayor actividad y, lo que es más importante, se notó mucho en los peores momentos de las consultas que tocaban muchas tablas (lo cual es lógico, tienen que obtener menos bloqueos y esas tablas laterales a menudo se usan en casi todas partes, a menudo disminuyendo de 7-8 a 4 mesas que deben bloquearse)
Pero tenga mucho cuidado al agregarlo, no se apresure y no lo haga de manera rutinaria. No duele cuando se usa correctamente, pero duele terriblemente cuando se usa incorrectamente.
No lo use para cosas muy críticas, cosas que calculan, etc., porque se volverá inconsistente, cualquier cosa que lleve a una escritura tarde o temprano.
Otra optimización de este tipo es ROWLOCK, que solo se bloquea en el nivel de fila. Esto es principalmente útil al actualizar (o eliminar) tablas en las que las filas no están relacionadas entre sí, como tablas en las que solo ingresa registros (y el orden en que se insertan no importa). Si tiene un esquema en el que en algún lugar al final de una transacción se escribe un registro en alguna tabla, esto también puede acelerarse considerablemente.
Si su base de datos tiene un porcentaje relativamente bajo de escrituras, es posible que no valga la pena. Tenía una proporción de lectura:escritura inferior a 2:1.
Algunas URL que guardé mientras trabajaba en esto:
http://www.developerfusion.com/article/1688/ sql-servidor-bloqueos/4/
