Servidor SQL: ¿[SELECCIONAR] bloquear [ACTUALIZAR]?

Question

Tengo una consulta de selección compleja y una tabla enorme.

estoy corriendo esta declaración select, por su parte una declaración Update llega y trata de actualización de la tabla.

mi humilde opinión - de actualización requiere un bloqueo exclusivo - por lo que la instrucción de actualización tendrá que esperar hasta que se termina el comando select.

1. Am I right?

2. ¿qué puedo hacer con el fin de: ejecutar el complejo select, y también dejar correr el comando update (actualmente no se preocupan por los datos sucios)

Answer 1

Sí - a un grado

el tiempo que un SELECT se aferra a un bloqueo compartido está en función del nivel de aislamiento de la transacción:

• READ UNCOMMITTED - sin bloqueo compartido se adquiere en absoluto - UPDATE no está bloqueado
• READ COMMITTED - Compartido el bloqueo se adquiere solo mientras dure la lectura de los datos: UPDATE puede estar bloqueado durante un período de tiempo muy corto
• REPEATABLE READ y SERIALIZABLE - el bloqueo compartido se adquiere y mantiene en unti l al final de la transacción - UPDATE se bloquea hasta que la transacción SELECT termina

Técnicamente, la declaración UPDATE primera consigue un bloqueo UPDATE - que es compatible con un bloqueo compartido (tal como se utiliza por el SELECT) - para la duración del tiempo mientras lee los valores actuales de las filas a actualizar.

Una vez hecho esto, el bloqueo Update se escala a un bloqueo exclusivo para que los nuevos datos se escriban en la tabla.

Answer 2

Cuando ejecuta las dos declaraciones al mismo tiempo (un SELECT y una ACTUALIZACIÓN) el comportamiento real será básicamente aleatorio. Esto es porque ninguna de las operaciones es instantánea. Para simplificar, considere su tabla una lista y SELECCIONAR está atravesando esta lista, mirando una fila a la vez. ACTUALIZAR también está tratando de actualizar una o más filas. Cuando la actualización está tratando de actualizar una fila detrás de SELECT, no ocurre nada (sin bloqueo) porque el SELECT ya ha progresado más allá del punto de ACTUALIZACIÓN. Si la actualización está tratando de actualizar la fila en la que SELECT está buscando en este momento, entonces la actualización tendrá que esperar que SELECT continúe, lo que ocurrirá muy, muy muy rápido y la actualización se desbloqueará y tendrá éxito, mientras que SELECT está avanzando. Pero si la ACTUALIZACIÓN está actualizando una fila adelante del SELECTO entonces la actualización tendrá éxito y, más tarde, SELECCIONARÁ finalmente llegará exactamente a esta fila y se detendrá, bloqueado.Ahora SELECT tiene que esperar hasta que la transacción que realizó UPDATE confirme.

Esta es la historia simplificada. La vida real es mucho más complicada. El SELECCIONAR puede tener puntos de lectura múltiples (planes paralelos). Tanto el SELECCIONAR como la ACTUALIZACIÓN están sujetas a elegir una ruta de acceso, es decir, usar uno o más índices secundarios para ubicar las filas. Las consultas complejas pueden contener operadores que causan búsquedas múltiples en una tabla (por ejemplo, uniones). Tanto SELECT como UPDATE pueden hacer búsquedas en los marcadores para obtener datos BLOB, lo que cambia significativamente el comportamiento de bloqueo. La estimación de cardinalidad puede hacer que SELECT se ejecute en un modo de bloqueo de granularidad alta (por ejemplo, bloqueo compartido de nivel de tabla). La ACTUALIZACIÓN puede desencadenar escalada de bloqueo y la escalada puede fallar o tener éxito. Choosing different access paths can lead to deadlock. False lock contention can occur due to hash collisions. Hay casi una miríada de variables que tienen voz en esto. Y ni siquiera mencioné niveles de aislamiento más altos (lectura repetible, serializable).

Quizás debería usar el aislamiento SNAPSHOT y dejar de preocuparse por este problema?