Bloqueo optimizado

Se aplica a: SQL Server 2025 (17.x) , Azure SQL Database, Azure SQL Managed Instance, Base de datos SQL en Microsoft Fabric

El bloqueo optimizado ofrece un mecanismo mejorado de bloqueo de transacciones para reducir los conflictos de bloqueo y el consumo de memoria en transacciones concurrentes.

¿Qué es el bloqueo optimizado?

El bloqueo optimizado ayuda a reducir la memoria de bloqueo, ya que se mantienen muy pocos bloqueos para transacciones grandes. Además, el bloqueo optimizado evita las escalaciones de bloqueo y puede evitar determinados tipos de interbloqueos. Esto permite un acceso más simultáneo a la tabla.

El bloqueo optimizado se compone de dos componentes principales: bloqueo de identificador de transacción (TID) y bloqueo después de la calificación (LAQ).

Un identificador de transacción (TID) es un identificador único de una transacción. Cada fila se etiqueta con el último TID que lo modificó. En lugar de tener potencialmente múltiples bloqueos de identificadores de clave o fila, se utiliza un único bloqueo en el TID para proteger todas las filas que han sido modificadas. Para obtener más información, consulte Bloqueo de ID de transacción (TID).
El bloqueo después de la calificación (LAQ) es una optimización que evalúa predicados de una consulta en la versión confirmada más reciente de la fila sin adquirir un bloqueo, lo que mejora la simultaneidad. LAQ requiere aislamiento de instantánea confirmada de lectura (RCSI). Para obtener más información, consulte Bloqueo tras cualificación (LAQ).

Por ejemplo:

Sin un bloqueo optimizado, la actualización de 1000 filas de una tabla podría requerir 1000 bloqueos de fila exclusivos (X) hasta el final de la transacción.
Con el bloqueo optimizado, la actualización de 1000 filas en una tabla podría requerir 1000 X bloqueos de fila, pero cada bloqueo se libera en cuanto se actualiza cada fila y solo se mantiene un X bloqueo TID hasta el final de la transacción. Debido a que los bloqueos se liberan rápidamente, el uso de memoria de bloqueo se reduce y es mucho menos probable que ocurra una escalada de bloqueos, mejorando la concurrencia de la carga de trabajo.

Note

La activación del bloqueo optimizado reduce o elimina los bloqueos de fila y página adquiridos por las instrucciones del lenguaje de modificación de datos (DML) como INSERT, UPDATE, DELETE, MERGE. No afecta a otros tipos de bloqueos de bases de datos y objetos, como los bloqueos de esquema.

Availability

En la tabla siguiente se resumen la disponibilidad y el estado habilitado del bloqueo optimizado en las plataformas SQL.

Platform	Available	Habilitado de forma predeterminada
Azure SQL Database	Yes	Sí (siempre habilitado)
Base de datos SQL en Microsoft Fabric	Yes	Sí (siempre habilitado)
^{Instancia administrada de Azure SQL AUTD}	Yes	Sí (siempre habilitado)
Instancia administrada de Azure SQL²⁰²⁵	Yes	Sí (siempre habilitado)
Instancia administrada de Azure SQL²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	No (se puede habilitar por base de datos)
SQL Server 2022 (16.x) y versiones anteriores	No	N/A

Habilitar y deshabilitar

Para habilitar o deshabilitar el bloqueo optimizado para una base de datos de SQL Server, use el ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF comando . Para obtener más información, consulte Opciones de ALTER DATABASE SET.

El bloqueo optimizado se basa en otras características de base de datos:

Debe habilitar la recuperación acelerada de bases de datos (ADR) en una base de datos para poder habilitar el bloqueo optimizado. Por el contrario, para desactivar ADR, debe desactivar primero el bloqueo optimizado si está activado.
Para obtener la mayor ventaja del bloqueo optimizado, se debe habilitar el aislamiento de instantánea de lectura confirmada (RCSI) para la base de datos. El componente LAQ del bloqueo optimizado solo tiene efecto si RCSI está habilitado.

ADR siempre está habilitado en Azure SQL Database, Azure SQL Managed Instance y SQL Database en Microsoft Fabric. RCSI está habilitado de forma predeterminada en Azure SQL Database y SQL Database en Microsoft Fabric.

Para verificar que estas opciones están habilitadas para su base de datos actual, conéctese a la base de datos y ejecute la siguiente consulta T-SQL:

SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_read_committed_snapshot_on,
       is_optimized_locking_on
FROM sys.databases
WHERE name = DB_NAME();

¿Está habilitado el bloqueo optimizado?

El bloqueo optimizado está habilitado por base de datos. Conéctese a la base de datos y, a continuación, utilice la siguiente consulta para comprobar si el bloqueo optimizado está habilitado:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

Result	Description
`0`	El bloqueo optimizado está desactivado.
`1`	El bloqueo optimizado está activado.
`NULL`	El bloqueo optimizado no está disponible.

También puede usar la vista de catálogo sys.databases . Por ejemplo, para ver si el bloqueo optimizado está habilitado para todas las bases de datos, ejecute la consulta siguiente:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Descripción general del bloqueo

Este es un breve resumen del comportamiento cuando el bloqueo optimizado no está habilitado. Para obtener más información, revise la guía de control de versiones de fila y bloqueo de transacciones.

En el motor de base de datos, el bloqueo es un mecanismo que impide que varias transacciones actualicen simultáneamente los mismos datos para garantizar las propiedades ACID de las transacciones.

Cuando una transacción necesita modificar datos, solicita un bloqueo sobre los mismos. Se concede el bloqueo si no se mantienen otros bloqueos conflictivos en los datos y la transacción puede continuar con la modificación. Si se mantiene otro bloqueo en conflicto en los datos, la transacción debe esperar a que se libere el bloqueo para poder continuar.

Cuando varias transacciones intentan acceder simultáneamente a los mismos datos, el motor de base de datos debe resolver conflictos potencialmente complejos con lecturas y escrituras simultáneas. El bloqueo es uno de los mecanismos mediante los cuales el motor puede proporcionar la semántica para los niveles de aislamiento de transacciones ANSI SQL. Aunque el bloqueo en las bases de datos es esencial, la reducción de la simultaneidad, los interbloqueos, la complejidad y la sobrecarga de bloqueo pueden afectar al rendimiento y la escalabilidad.

Bloqueo del identificador de transacción (TID)

Cuando se utilizan niveles de aislamiento basados en versionado de filas o cuando ADR está activado, cada fila de la base de datos contiene internamente un identificador de transacción (TID). TID se conserva con la fila. Cada transacción que modifica una fila marca la fila con su TID.

Con el bloqueo de TID, en lugar de tomar el bloqueo en la clave de la fila, se toma un bloqueo en el TID de la fila. La transacción modificadora mantiene un bloqueo X sobre su TID. Otras transacciones adquieren un bloqueo S sobre el TID para esperar hasta que la primera transacción finalice. Con el bloqueo TID, los bloqueos de página y fila se siguen tomando para las modificaciones, pero cada bloqueo de página y fila se libera tan pronto como se modifica cada fila. El único bloqueo que se mantiene hasta el final de la transacción es el único bloqueo X del recurso TID, que sustituye a los múltiples bloqueos de página y fila (clave).

Considere el siguiente ejemplo que muestra los bloqueos para la sesión actual mientras una transacción de escritura está activa:

/* Is optimized locking is enabled? */
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn') AS is_optimized_locking_enabled;

CREATE TABLE t0
(
a int PRIMARY KEY,
b int NULL
);

INSERT INTO t0 VALUES (1,10),(2,20),(3,30);
GO

BEGIN TRANSACTION;

UPDATE t0
SET b = b + 10;

SELECT *
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
      AND
      resource_type IN ('PAGE','RID','KEY','XACT');

COMMIT TRANSACTION;
GO

DROP TABLE IF EXISTS t0;

Si el bloqueo optimizado está activado, la petición mantiene un único bloqueo X sobre el recurso XACT (transacción).

Si el bloqueo optimizado no está habilitado, la misma solicitud contiene cuatro bloqueos: un bloqueo IX (exclusivo de intención) en la página que contiene las filas y tres bloqueos de clave X en cada fila:

La sys.dm_tran_locks vista de administración dinámica (DMV) es útil para examinar o solucionar problemas de bloqueo. Aquí se utiliza para observar el funcionamiento del bloqueo optimizado en acción.

Bloqueo después de la calificación (LAQ)

Basándose en la infraestructura de TID, el componente LAQ de bloqueo optimizado cambia la forma en que las instrucciones DML, como INSERT, UPDATEy DELETE adquieren bloqueos.

Sin bloqueo optimizado, los predicados de consulta se comprueban fila a fila en una exploración tomando primero un bloqueo de fila de actualización (U). Si se cumple el predicado, se toma un bloqueo de fila exclusivo (X) antes de actualizar la fila y se mantiene hasta el final de la transacción.

Con el bloqueo optimizado y, cuando se habilita el READ COMMITTED nivel de aislamiento de instantáneas (RCSI), los predicados se pueden comprobar optimistamente en la versión confirmada más reciente de la fila sin tomar ningún bloqueo. Si el predicado no cumple, la consulta se mueve a la siguiente fila del examen. Si se cumple el predicado, se toma un bloqueo de fila X para actualizar la fila.

En otras palabras, el bloqueo se toma después de la calificación de la fila para su modificación. El bloqueo de fila X se libera tan pronto como se completa la actualización de la fila, antes del final de la transacción.

Dado que la evaluación del predicado se realiza sin adquirir bloqueos, las consultas simultáneas que modifican filas diferentes no se bloquearán entre sí.

Por ejemplo:

/* Confirm that optimized locking and read committed snapshot isolation (RCSI) are both enabled on this database. */
SELECT database_id,
       name,
       is_accelerated_database_recovery_on,
       is_optimized_locking_on,
       is_read_committed_snapshot_on
FROM sys.databases
WHERE name = DB_NAME();

CREATE TABLE t1
(
a int NOT NULL,
b int NULL
);

INSERT INTO t1
VALUES (1,10),(2,20),(3,30);
GO

Sesión 1	Sesión 2
`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t1` `SET b = b + 10` `WHERE a = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Sin bloqueo optimizado, la sesión 2 se bloquea porque la sesión 1 tiene un bloqueo U en la fila que la sesión 2 necesita actualizar. Sin embargo, con el bloqueo optimizado, la sesión 2 no se bloquea porque los bloqueos U no están tomados, y porque en la última versión confirmada de la fila 1, la columna a es igual a 1, lo que no satisface el predicado de la sesión 2.

LAQ se realiza de forma optimista suponiendo que una fila no se modifica después de comprobar el predicado. Si se cumple ese predicado y la fila no se ha modificado tras verificar dicho predicado, la transacción actual la modifica.

Dado que no se toman los U bloqueos, una transacción concurrente podría modificar la fila después de evaluar el predicado. Si hay una transacción activa que contiene un X bloqueo TID en la fila, el motor de base de datos espera a que se complete. Si la fila ha cambiado después de evaluar el predicado anteriormente, el motor de base de datos vuelve a evaluar (vuelve a calificar) el predicado antes de modificar la fila. Si se sigue cumpliendo el predicado, se modifica la fila.

La recalificación de predicado es compatible con un subconjunto de operadores del motor de consulta. Si se necesita la reevaluación de un predicado, pero el plan de consulta utiliza un operador que no admite esta reevaluación, el motor de la base de datos anula internamente el procesamiento de la instrucción y lo reinicia sin LAQ. Cuando se produce una interrupción de este tipo, se activa el evento extendido lock_after_qual_stmt_abort.

Algunas instrucciones, por ejemplo UPDATE , con la asignación de variables y las instrucciones con la cláusula OUTPUT , no se pueden anular ni reiniciar sin cambiar su semántica. Para estas declaraciones, no se usa LAQ.

En el ejemplo siguiente, el predicado se vuelve a evaluar porque otra transacción ha cambiado la fila:

CREATE TABLE t3
(
a int NOT NULL,
b int NULL
);

INSERT INTO t3 VALUES (1,10),(2,20),(3,30);
GO

Sesión 1	Sesión 2
`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
	`BEGIN TRANSACTION;` `UPDATE t3` `SET b = b + 10` `WHERE a = 1;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Omitir bloqueos de índice (SIL)

Con el bloqueo de TID, los bloqueos de fila exclusivos (X) de corta duración y los bloqueos de página exclusivos de intención (IX) se usan para modificar las filas. Cuando se utilizan RCSI y LAQ, estos bloqueos solo son necesarios si podría haber otras consultas que accedan a la fila y esperen que se mantenga estable. Algunos ejemplos de estas consultas son aquellos que se ejecutan bajo los niveles de aislamiento REPEATABLE READ o SERIALIZABLE, o utilizando las indicaciones de bloqueo correspondientes. Estas consultas se conocen como consultas de bloqueo de filas (RLQ).

Cuando no hay consultas RLQ que accedan a una fila, el motor de base de datos puede omitir la toma de bloqueos de fila y página cuando se modifica una fila y usar solo un cerrojo exclusivo de página. Esta optimización reduce la sobrecarga de bloqueo al tiempo que conserva la semántica de las transacciones ACID. Omitir los bloqueos de fila y página beneficia especialmente a las transacciones que modifican un gran número de filas.

Actualmente, la optimización de SIL solo se usa en los casos siguientes:

INSERT instrucciones en montones.
- IX Se omiten los bloqueos de página.
UPDATE instrucciones en índices agrupados, índices no agrupados y montones.
- IX Se omiten los bloqueos de página y X los bloqueos de fila.

La optimización de SIL no se usa actualmente en los casos siguientes:

InstruccionesDELETE .
UPDATE declaraciones en estructuras heap si la fila contiene punteros de reenvío existentes o si la actualización agrega nuevos punteros de reenvío.
Si la fila modificada tiene columnas con los tipos de datos LOB, como varchar(max), nvarchar(max), varbinary(max)y json.
Para las filas de las páginas que se dividieron en la misma transacción.

Heurística LAQ

Como se describe en Bloqueo después de la calificación (LAQ), cuando se usa LAQ, las declaraciones que usan operadores de consulta que no admiten la recalificación de predicados podrían reiniciarse y procesarse internamente sin LAQ. Si esto sucede con frecuencia, la sobrecarga del reprocesamiento podría ser significativa. Para minimizar la sobrecarga, el bloqueo optimizado usa un mecanismo de retroalimentación basado en heurísticas que deshabilita LAQ si la sobrecarga supera los umbrales establecidos.

Para el propósito del mecanismo de retroalimentación, el trabajo realizado por una instrucción se mide en la cantidad de lecturas lógicas. Si el motor de base de datos está modificando una fila que fue modificada por otra transacción después de que comenzó el procesamiento de la declaración, el trabajo realizado por la declaración se considera potencialmente desperdiciado porque es posible que la declaración tenga que volver a procesarse.

A medida que se ejecutan instrucciones, el motor de base de datos mantiene los datos de comentarios de LAQ que realizan un seguimiento del trabajo potencialmente desperdiciado, las repeticiones del reprocesamiento de instrucciones y el trabajo total realizado por las instrucciones que podrían volver a procesarse.

LAQ se deshabilita si la proporción del trabajo potencialmente desperdiciado con el trabajo total o la proporción del número de instrucciones reprocesadas al número total de instrucciones supera sus umbrales respectivos. Si cualquiera de estos ratios descienden por debajo de los umbrales, se re-habilita LAQ.

Se realiza un seguimiento de los datos de comentarios de LAQ en dos niveles:

Para un plan de consulta.
- El motor de base de datos comienza a rastrear la retroalimentación de LAQ para un plan desde la primera instancia del reprocesamiento de sentencias.
- Si una consulta se captura en el Almacén de consultas, los comentarios de LAQ también se capturan en el Almacén de consultas. El motor de base de datos usa estos comentarios para mantener LAQ habilitado o deshabilitado para el plan si se reinicia la base de datos.
- Los planes de consulta con comentarios LAQ capturados tienen una fila con un valor coincidente plan_id en la vista de catálogo sys.query_store_plan_feedback. Las feature_id columnas y feature_desc se establecen en 4 y LAQ Feedback respectivamente.
Para una base de datos.
- La retroalimentación se recopila para todas las instrucciones que no tienen retroalimentación a nivel de plan de consulta, por ejemplo, si una consulta no se captura en Query Store.
- Se realiza un seguimiento de la retroalimentación desde el inicio de la base de datos y se recrea después de cada inicio.

Al decidir si se debe usar LAQ para una instrucción, el sistema usa los comentarios del plan de consulta si están disponibles. De lo contrario, usa la retroalimentación a nivel de base de datos. Esto significa que algunas instrucciones pueden ejecutarse con LAQ y algunas podrían ejecutarse sin LAQ. Por ejemplo, LAQ podría estar deshabilitado para un plan de consulta, pero habilitado para la base de datos y viceversa.

Limitaciones de LAQ

El bloqueo después de la calificación no se usa en los escenarios siguientes:

Cuando se desactiva por la heurística LAQ.
Cuando se usan sugerencias de bloqueo conflictivas, como UPDLOCK, READCOMMITTEDLOCK, XLOCK o HOLDLOCK.
Cuando el nivel de aislamiento de transacción es distinto de READ COMMITTED, o cuando la opción de base de datos READ_COMMITTED_SNAPSHOT está deshabilitada.
Cuando la tabla que se está modificando tiene un índice de almacén de columnas.
Cuando la instrucción DML incluye la asignación de variables.
Cuando la instrucción DML tiene una cláusula OUTPUT.
Cuando la instrucción DML utiliza más de un operador de búsqueda o exploración de índice para leer las filas que están siendo modificadas.
En instrucciones MERGE.

Cambios de comportamiento de consulta con bloqueo optimizado y RCSI

Las cargas de trabajo concurrentes bajo aislamiento instantáneo de lectura comprometida (RCSI) que dependen de un orden de ejecución estricto de las transacciones podrían experimentar diferencias en el comportamiento de las consultas cuando se habilita el bloqueo optimizado.

Considere el ejemplo siguiente en el que la transacción T2 actualiza la tabla t4 en función de la columna b que se actualizó durante la transacción T1.

CREATE TABLE t4
(
a int NOT NULL,
b int NULL
);

INSERT INTO t4
VALUES (1,1);
GO

Sesión 1	Sesión 2
`BEGIN TRANSACTION T1;` `UPDATE t4` `SET b = 2` `WHERE a = 1;`
	`BEGIN TRANSACTION T2;` `UPDATE t4` `SET b = 3` `WHERE b = 2;`
`COMMIT TRANSACTION;`
	`COMMIT TRANSACTION;`

Evaluemos el resultado del escenario anterior con y sin bloqueo tras cualificación (LAQ).

Sin LAQ

Sin LAQ, la instrucción UPDATE de la transacción T2 está bloqueada, esperando a que se complete la transacción T1. Una vez que T1 finaliza, T2 actualiza la fila que establece la columna b en 3 porque se satisface su predicado.

Tras la confirmación de ambas transacciones, la tabla t4 contiene las siguientes filas:

 a | b
 1 | 3

Con LAQ

Con LAQ, la transacción T2 utiliza la última versión confirmada de la fila en la que la columna b es igual a 1 para evaluar su predicado (b = 2). La fila no cumple los requisitos; por lo tanto, se omite y la instrucción se completa sin haber sido bloqueado por la transacción T1. En este ejemplo, LAQ quita el bloqueo, pero conduce a resultados diferentes.

Tras la confirmación de ambas transacciones, la tabla t4 contiene las siguientes filas:

 a | b
 1 | 2

Important

Incluso sin LAQ, las aplicaciones no deben suponer que el motor de base de datos garantiza un orden estricto sin usar indicaciones de bloqueo cuando se utilizan niveles de aislamiento basados en el versionado de filas. Nuestra recomendación general para los clientes que ejecutan cargas de trabajo concurrentes bajo RCSI que dependen de un orden de ejecución estricto de las transacciones (como se muestra en el ejemplo anterior) es utilizar niveles de aislamiento más estrictos como REPEATABLE READ y SERIALIZABLE.

Adiciones de diagnóstico para el bloqueo optimizado

Las siguientes mejoras le ayudarán a monitorizar y solucionar problemas de bloqueos y deadlocks cuando el bloqueo optimizado está habilitado:

Tipos de espera para el bloqueo optimizado
- XACT tipos de espera para el bloqueo en el TID, y descripciones de recursos en S:
  - LCK_M_S_XACT_READ: se produce cuando una tarea está esperando un bloqueo compartido en un tipo XACTwait_resource, con una intención de leer.
  - LCK_M_S_XACT_MODIFY: se produce cuando una tarea está esperando un bloqueo compartido en un tipo XACTwait_resource, con una intención de modificar.
  - LCK_M_S_XACT: se produce cuando una tarea está esperando un bloqueo compartido en un tipo XACTwait_resource, donde la intención no puede ser inferida. Este escenario no es común.
Visibilidad de los recursos de bloqueo
- Recursos de bloqueo de XACT. Para obtener más información, consulte resource_description en sys.dm_tran_locks.
Visibilidad de los recursos de espera
- Recursos de espera de XACT. Para obtener más información, consulte wait_resource en sys.dm_exec_requests.
Gráfico de interbloqueo
- Bajo cada recurso del informe de bloqueo <resource-list>, cada elemento <xactlock> informa de los recursos subyacentes y de la información específica de los bloqueos de cada miembro de un bloqueo. Para obtener más información y un ejemplo, consulta Bloqueos optimizados e interbloqueos.
Eventos extendidos
- El lock_after_qual_stmt_abort evento se desencadena cuando una instrucción se vuelve a procesar internamente debido a un conflicto con otra transacción. Para obtener más información, consulte Bloqueo tras cualificación (LAQ).
- El locking_stats evento se activa para cada base de datos cada pocos minutos y proporciona estadísticas de bloqueo agregadas para el intervalo de tiempo, como el número de escalaciones de bloqueo, si el bloqueo TID y los componentes LAQ del bloqueo optimizado están habilitados, y el número de consultas en las que no se utilizó LAQ por varias razones. Este evento se desencadena aunque el bloqueo optimizado esté deshabilitado.
- En SQL Server y Azure SQL Managed Instance, el locking_stats2 evento se desencadena por cada base de datos cada pocos minutos y proporciona los bloqueos de índice omitados y las estadísticas heurísticas LAQ para el intervalo de tiempo.

Procedimientos recomendados con bloqueo optimizado

Habilitación del aislamiento de instantánea de lectura confirmada (RCSI)

Para maximizar las ventajas del bloqueo optimizado, se recomienda habilitar el aislamiento de instantáneas confirmadas (RCSI) de lectura en la base de datos y usar este aislamiento como nivel de aislamiento predeterminado.

En Azure SQL Database y SQL Database en Microsoft Fabric, RCSI está habilitado de forma predeterminada y READ COMMITTED es el nivel de aislamiento predeterminado. Con RCSI habilitado y cuando se utiliza READ COMMITTED nivel de aislamiento, los lectores leen una versión de la fila de la instantánea tomada al inicio de la instrucción. Con LAQ, los escritores califican las filas según el predicado basándose en la última versión confirmada de la fila y sin adquirir bloqueos U. Con LAQ, una consulta solo espera si la fila cumple los requisitos y hay una transacción de escritura activa en esa fila. Calificar según la versión confirmada más reciente y bloquear solo las filas calificadas reduce el bloqueo y aumenta la simultaneidad.

Evitar sugerencias de bloqueo

Aunque las sugerencias de tabla y consulta como UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCK, etc. se respetan cuando está activado el bloqueo optimizado, reducen el beneficio del bloqueo optimizado. Las sugerencias de bloqueo obligan al motor de la base de datos a tomar bloqueos de fila o página y mantenerlos hasta el final de la transacción, para cumplir con la intención de las sugerencias de bloqueo. Algunas aplicaciones tienen una lógica en la que los indicios de bloqueo son necesarios, por ejemplo, cuando se lee una fila con el indicio UPDLOCK y se actualiza más tarde. Se recomienda usar sugerencias de bloqueo solo cuando sea necesario.

Con el bloqueo optimizado, no hay restricciones en las consultas existentes y no es necesario reescribir las consultas. Las consultas que no utilizan indicaciones se benefician más del bloqueo optimizado.

Una sugerencia de tabla en una tabla de una consulta no deshabilitará el bloqueo optimizado para otras tablas de la misma consulta. Además, el bloqueo optimizado solo afecta al comportamiento de bloqueo de las tablas que se actualizan mediante una instrucción DML como INSERT, UPDATE, DELETE o MERGE. Por ejemplo:

CREATE TABLE t5
(
a int NOT NULL,
b int NOT NULL
);

CREATE TABLE t6
(
a int NOT NULL,
b int NOT NULL
);
GO

INSERT INTO t5 VALUES (1,10),(2,20),(3,30);
INSERT INTO t6 VALUES (1,10),(2,20),(3,30);
GO

UPDATE t5 SET t5.b = t6.b
FROM t5
INNER JOIN t6 WITH (UPDLOCK)
ON t5.a = t6.a;

En el ejemplo de consulta anterior, solo la tabla t6 se verá afectada por la sugerencia de bloqueo, mientras que t5 todavía puede beneficiarse del bloqueo optimizado.

UPDATE t5
    SET t5.b = t6.b
FROM t5 WITH (REPEATABLEREAD)
     INNER JOIN t6
         ON t5.a = t6.a;

En el ejemplo de consulta anterior, solo la tabla t5 utiliza el nivel de aislamiento REPEATABLE READ y mantiene los bloqueos hasta el final de la transacción. Otras actualizaciones de t5 pueden seguir beneficiándose del bloqueo optimizado. Lo mismo se aplica a la sugerencia HOLDLOCK.

Preguntas más frecuentes

¿Está optimizado el bloqueo de forma predeterminada en bases de datos nuevas y existentes?

En Azure SQL Database, AZURE SQL Managed Instance^AUTD y SQL Database en Microsoft Fabric, sí. En SQL Server 2025 (17.x) el bloqueo optimizado está deshabilitado de forma predeterminada, pero se puede habilitar en cualquier base de datos de usuario que tenga habilitada la recuperación acelerada de la base de datos.

¿Cómo puedo detectar si el bloqueo optimizado está habilitado?

Consulte ¿Está habilitado el bloqueo optimizado?

¿Qué ocurre si quiero forzar que las consultas se bloqueen a pesar del bloqueo optimizado?

Si RCSI está activado, utilice la sugerencia de tabla READCOMMITTEDLOCK para forzar el bloqueo entre dos consultas cuando el bloqueo optimizado está activado.

¿Se utiliza el bloqueo optimizado en réplicas secundarias de solo lectura?

No, porque las instrucciones DML no pueden ejecutarse en réplicas de solo lectura, y no se toman los bloqueos de fila y página correspondientes.

¿Se utiliza el bloqueo optimizado cuando se modifican datos en tempdb y en tablas temporales?

De momento, no.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2025-11-24