el otro día, durante el taller práctico de ajuste de rendimiento de SQL Server, entré en una situación muy interesante. Al afinar una consulta tuvimos una situación en la que tuvimos que comprobar si la consulta está bloqueada durante la ejecución de not., Para probar nuestra teoría tuvimos que poner una pista nolock para cada tabla de la consulta larga. Sin embargo, no era posible hacerlo, ya que el procedimiento almacenado era súper enorme e involucraba más de 90 tablas y 14 vistas en múltiples sentencias SQL. De hecho, fue un gran desafío para un equipo de desarrolladores modificar ese SP. Si alguna vez se enfrenta a tales situaciones, no debe estresarse. Hay una forma mucho más sencilla de leer datos no comprometidos.,
antes de Continuar leyendo esta publicación de blog, tenga en cuenta que personalmente no prefiero usar para bloquear sugerencias en mi negocio, ya que leerá los datos sucios y, a menudo, leer datos no comprometidos crea problemas con la integridad de la base de datos. Hay muchas maneras diferentes de ajustar su consulta en lugar de usar NOLOCK hint o usar READ uncommitted transaction isolation.
veamos primero un ejemplo sencillo de cómo funciona NOLOCK hint con varias tablas.,
ahora convertiremos el mismo script para usar el aislamiento de transacciones no comprometidas de lectura.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDGOSELECT *FROM . ctINNER JOIN . spON ct.StateProvinceID = sp.StateProvinceIDGOSET TRANSACTION ISOLATION LEVEL READ COMMITTEDGO
Técnicamente, no hay absolutamente ninguna diferencia entre el rendimiento y el impacto de los dos métodos. Prefiero usar el segundo método más a menudo, ya que es más fácil escribir y probar. Una vez más, si es posible, me gusta evitar leer métodos no comprometidos para leer los datos.
