Optimalizované uzamčení

Platí pro: SQL Server 2025 (17.x) Azure SQL Database Azure SQL Managed Instance SQL Database v Microsoft Fabric

Optimalizované uzamykání nabízí vylepšený mechanismus uzamykání transakcí, který snižuje blokování a spotřebu paměti na uzamykání pro souběžné transakce.

Co je optimalizované uzamčení?

Optimalizované uzamykání pomáhá snížit paměť zámků, protože jen velmi málo zámků se uchovává i u velkých transakcí. Optimalizované uzamčení navíc zabraňuje eskalaci zámků a může se vyhnout určitým typům zablokování. To umožňuje více souběžného přístupu k tabulce.

Optimalizované zamykání se skládá ze dvou hlavních komponent: uzamčení ID transakce (TID) a uzamčení po kvalifikaci (LAQ).

ID transakce (TID) je jedinečný identifikátor transakce. Každý řádek je označený posledním TID, který ho upravil. Místo potenciálně mnoha zámků identifikátorů klíčů nebo řádků se k ochraně všech upravených řádků používá jeden zámek v TID. Další informace naleznete v tématu Uzamykání ID transakce (TID).
Zámek po kvalifikaci (LAQ) je optimalizace, která vyhodnocuje predikáty dotazů pomocí nejnovější potvrzené verze řádku bez získání zámku, čímž se zlepší souběžnost. LAQ vyžaduje izolaci snímků potvrzenou čtením (RCSI). Další informace naleznete v tématu Zámek po kvalifikaci (LAQ).

Například:

Bez optimalizovaného uzamčení může aktualizace 1 000 řádků v tabulce vyžadovat 1 000 výhradních (X) zámků řádků uchovávaných až do konce transakce.
Při optimalizovaném uzamčení může aktualizace 1 000 řádků v tabulce vyžadovat 1 000 X zámků řádků, ale každý zámek se uvolní, jakmile se každý řádek aktualizuje, a až do konce transakce se bude uchovávat pouze jeden X zámek TID. Vzhledem k tomu, že se zámky uvolňují rychle, snižuje se využití paměti zámků a eskalace zámků je mnohem méně pravděpodobná, což zlepšuje konkurenceschopnost úloh.

Note

Povolení optimalizovaného uzamčení snižuje nebo eliminuje zámky řádků a stránek, které jsou získávány operacemi DML (Data Modification Language), jako jsou INSERT, UPDATE, DELETE, MERGE. Nemá žádný vliv na jiné druhy zámků databáze a objektů, jako jsou zámky schématu.

Availability

Následující tabulka shrnuje dostupnost a povolený stav optimalizovaného uzamčení napříč platformami SQL.

Platform	Available	Ve výchozím nastavení povoleno
Azure SQL Database	Yes	Ano (vždy povoleno)
Databáze SQL v rámci Microsoft Fabric	Yes	Ano (vždy povoleno)
Azure SQL Managed Instance^AUTD	Yes	Ano (vždy povoleno)
Azure SQL Managed Instance²⁰²⁵	Yes	Ano (vždy povoleno)
Azure SQL Managed Instance²⁰²²	No	N/A
SQL Server 2025 (17.x)	Yes	Ne (pro každou databázi je možné povolit)
SQL Server 2022 (16.x) a starší verze	No	N/A

Povolení a zakázání

Pokud chcete povolit nebo zakázat optimalizované uzamčení pro databázi SQL Serveru, použijte ALTER DATABASE ... SET OPTIMIZED_LOCKING = ON | OFF tento příkaz. Další informace najdete v tématu Možnosti ALTER DATABASE SET.

Optimalizované uzamykání vychází z dalších databázových funkcí:

Abyste mohli povolit optimalizované uzamykání, musíte u databáze povolit zrychlené obnovení databáze (ADR ). Pokud chcete naopak zakázat ADR, musíte nejprve zakázat optimalizované uzamčení, pokud je povolené.
Pro většinu výhod optimalizovaného uzamčení by měla být pro databázi povolená izolace snímků potvrzené čtením (RCS I). Komponenta LAQ optimalizace uzamčení vejde v platnost pouze v případě, že je povolená RCSI.

Služba ADR je vždy povolená ve službě Azure SQL Database, Azure SQL Managed Instance a v databázi SQL v Microsoft Fabric. Analýza RCSI je ve výchozím nastavení povolená ve službě Azure SQL Database a v databázi SQL v Microsoft Fabric.

Pokud chcete ověřit, že jsou pro aktuální databázi povolené tyto možnosti, připojte se k databázi a spusťte následující dotaz 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();

Je optimalizované uzamčení povolené?

Optimalizované uzamčení je povolené pro každou databázi. Připojte se k databázi a pomocí následujícího dotazu zkontrolujte, jestli je povolené optimalizované uzamčení:

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

Result	Description
`0`	Optimalizované uzamčení je zakázáno.
`1`	Optimalizované uzamčení je povolené.
`NULL`	Optimalizované uzamčení není k dispozici.

Můžete také použít zobrazení katalogu sys.databases . Pokud chcete například zjistit, jestli je pro všechny databáze povolené optimalizované uzamčení, spusťte následující dotaz:

SELECT database_id,
       name,
       is_optimized_locking_on
FROM sys.databases;

Přehled uzamčení

Toto je krátký souhrn chování, pokud není povolené optimalizované uzamčení. Pro více informací si přečtěte průvodce o uzamčení transakcí a o správě verzí řádků.

V databázovém systému je zamykání mechanismus, který brání více transakcím v aktualizaci stejných dat zároveň, aby zajistil ACID vlastnosti transakcí.

Když transakce potřebuje upravit data, požádá o zámek dat. Zámek je udělen, pokud nejsou v datech uloženy žádné jiné konfliktní zámky a transakce může pokračovat v úpravě. Pokud se na datech uchovává jiný konfliktní zámek, transakce musí počkat, až se zámek uvolní, než bude možné pokračovat.

Když se více transakcí pokusí získat přístup ke stejným datům současně, databázový stroj musí vyřešit potenciálně složité konflikty se souběžnými čteními a zápisy. Uzamčení je jedním z mechanismů, kterými může modul poskytovat sémantiku pro transakci ANSI SQL úrovně izolace. I když je zamykání v databázích nezbytné, snížená souběžnost, zablokování, složitost a režijní náklady na uzamčení mohou ovlivnit výkon a škálovatelnost.

Uzamčení ID transakce (TID)

Při správy verzí řádků úrovně izolace založené na základech se používají nebo když je povolená možnost ADR, každý řádek v databázi interně obsahuje ID transakce (TID). TID se uloží s řádkem. Každá transakce, která upravuje řádek, označí řádek svým TID.

V zamykání pomocí TID se místo zamčení klíče řádku přebírá zámek na TID řádku. Modifikující transakce má X zámek na svém TID. Ostatní transakce získávají zámek S na TID, aby vyčkaly na dokončení první transakce. Při uzamčení TID se zámky pro stránky a řádky používají nadále při úpravách, ale každý zámek pro stránku a řádek se uvolní, jakmile je daný řádek upraven. Jediným zámkem drženým až do konce transakce je jeden zámek X na prostředku TID, který nahrazuje více zámků na stránkách a řádcích (klíče).

Podívejte se na následující příklad, který ukazuje zámky pro aktuální sezení, zatímco je transakce zápisu aktivní:

/* 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;

Pokud je povolené optimalizované uzamčení, požadavek obsahuje pouze jeden zámek X na prostředku XACT (transakce).

Pokud není optimalizované uzamčení povolené, obsahuje stejný požadavek čtyři zámky – jeden zámek IX (výhradní záměr) na stránce obsahující řádky a tři X zámky kláves na každém řádku:

Dynamické správní zobrazení (DMV) sys.dm_tran_locks je užitečné při zkoumání nebo řešení problémů se zámky. Tady se používá k sledování optimalizovaného zamykání v akci.

Zámek po kvalifikaci (LAQ)

Komponenta LAQ pro optimalizované zamykání vychází z infrastruktury TID a mění způsob, jakým příkazy DML, jako INSERT, UPDATE a DELETE získávají zámky.

Bez optimalizovaného zamykání se predikáty dotazu kontrolují řádek po řádku ve skenu, přičemž nejprve je použit zámek řádku pro aktualizaci (U). Pokud je predikát splněn, před aktualizací řádku se převezme exkluzivní zámek řádku (X), který je držen až do konce transakce.

Při optimalizovaném uzamčení a když je povolena úroveň izolace snímků READ COMMITTED (RCSI), lze predikáty zkontrolovat optimisticky na nejnovější potvrzené verzi řádku bez nutnosti používat zámky. Pokud predikát nevyhovuje, dotaz se přesune na další řádek prohledávání. Pokud je predikát splněný, je uzamčen řádek X, aby se řádek aktualizoval.

Jinými slovy, zámek je uplatněn po kvalifikaci řádku k úpravě. Zámek řádku X se uvolní hned po dokončení aktualizace řádku před koncem transakce.

Vzhledem k tomu, že se vyhodnocení predikátu provádí bez získání zámků, souběžné dotazy, které upravují různé řádky, navzájem neblokují.

Například:

/* 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

sezení 1	Sezení 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;`

Bez optimalizovaného uzamčení je relace 2 blokovaná, protože relace 1 drží zámek typu U na řádku, který relace 2 potřebuje aktualizovat. S optimalizovaným uzamčením ale relace 2 není blokovaná, protože U zámky nejsou přijaty, a protože ve nejnovější potvrzené verzi řádku 1 se sloupec a rovná 1, což nesplňuje podmínku relace 2.

LAQ se provádí optimisticky za předpokladu, že se po ověření predikátu nezmění řádek. Pokud je predikát splněný a řádek se po kontrole predikátu nezměnil, upraví ho aktuální transakce.

U Vzhledem k tomu, že zámky nejsou pořízeny, může souběžná transakce po vyhodnocení predikátu upravit řádek. Pokud je na řádku aktivní transakce, která drží zámek "TID" X, databázový stroj počká na její dokončení. Pokud se řádek po vyhodnocení predikátu dříve změnil, databázový stroj znovu vyhodnotí predikát (znovu zkvalitní) predikát před úpravou řádku. Pokud je predikát stále splněn, řádek se upraví.

Překvalifikace predikátu je podporována podmnožinou operátorů dotazovacího stroje. Pokud je potřeba přehodnocení predikátu, ale plán dotazu používá operátor, který nepodporuje překvalifikaci predikátu, databázový stroj interně přeruší zpracování příkazů a restartuje ho bez laQ. Pokud dojde k takovému přerušení, spustí se rozšířená událost lock_after_qual_stmt_abort.

Některé příkazy, například UPDATE příkazy s přiřazením proměnné a příkazy s klauzulí OUTPUT , nelze přerušit a restartovat beze změny jejich sémantiky. U takových tvrzení se LAQ nepoužívá.

V následujícím příkladu se predikát znovu vyhodnotí, protože jiná transakce změnila řádek:

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

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

sezení 1	Sezení 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;`

Přeskočení zámků indexu (SIL)

Při uzamčení TID se k úpravě řádků používají exkluzivní zámky řádků s krátkou dobou trvání (X) a exkluzivní zámky stránek s výhradním záměrem (IX). Při použití RCSI a LAQ jsou tyto zámky nezbytné pouze v případě, že by mohly existovat další dotazy, které přistupují k řádku a očekávají, že řádek bude stabilní. Příklady takových dotazů jsou ty, které běží pod úrovní izolace REPEATABLE READ nebo používající odpovídající nápovědy k uzamčení SERIALIZABLE. Takové dotazy se označují jako dotazy pro zamykání řádků (RLQ).

Pokud k žádnému řádku nepřistupují dotazy RLQ, databázový stroj může při úpravě řádku přeskočit uzamčení řádku a stránky a použít pouze výhradní zámek stránky. Tato optimalizace snižuje náklady na uzamykání a zároveň zachovává vlastnosti transakce ACID. Přeskočení zámků řádků a stránek přináší zejména výhody transakcím, které upravují velký počet řádků.

V současné době se optimalizace SIL používá pouze v následujících případech:

INSERT příkazy o haldách.
- IX zámky stránek jsou přeskočeny.
UPDATE prohlášení o clusterovaných indexech, neklastrovaných indexech a haldách.
- IX zámky stránek a X zámky řádků jsou přeskočeny.

Optimalizace SIL se v současné době nepoužívá v následujících případech:

DELETE výroky.
UPDATE příkazy pro haldy, pokud řádek obsahuje existující ukazatele pro přesměrování nebo pokud aktualizace přidá nové ukazatele přesměrování.
Pokud má upravený řádek nějaké sloupce používající datové typy LOB, například varchar(max), nvarchar(max), varbinary(max)a json.
Pro řádky na stránkách, které byly rozděleny ve stejné transakci.

Heuristika LAQ

Jak je popsáno v části Zámek po kvalifikaci (LAQ) při použití příkazů LAQ, které používají operátory dotazů, které nepodporují překvalifikaci predikátu, se můžou interně restartovat a zpracovat bez LAQ. Pokud k tomu dojde často, může být režie opětovného zpracování významná. K minimalizaci režie používá optimalizované uzamčení mechanismus zpětné vazby založený na heuristice, který deaktivuje LAQ, pokud režie překročí prahové hodnoty.

Pro účely mechanismu zpětné vazby se práce provedená příkazem měří v počtu logických čtení. Pokud databázový stroj upravuje řádek, který byl změněn jinou transakcí po spuštění zpracování příkazu, pak práce provedená příkazem je považována za potenciálně plýtvání, protože příkaz může být potřeba znovu zpracovat.

Při provádění příkazů udržuje databázový stroj zpětnou vazbu ve formě dat LAQ, která sledují potenciálně zbytečnou práci, výskyty opětovného zpracování příkazů a celkovou práci provedenou příkazy, které mohou být znovu zpracovány.

Funkce LAQ je zakázána, pokud poměr potenciálně zbytečně vynaložené práce k celkové práci nebo poměr počtu reprocesovaných příkazů k celkovému počtu příkazů překračuje jejich příslušné prahové hodnoty. Pokud oba tyto poměry spadají pod prahové hodnoty, je hodnota LAQ znovu použitelná.

Data zpětné vazby LAQ se sledují na dvou úrovních:

Pro plán dotazu.
- Databázový systém začne sledovat zpětnou vazbu LAQ pro plán při prvním výskytu opětovného zpracování příkazu.
- Pokud je dotaz zachycený v úložišti dotazů, zaznamená se také zpětná vazba LAQ v úložišti dotazů. Databázový engine používá tuto zpětnou vazbu pro udržení LAQ povoleného nebo zakázaného pro plán při restartování databáze.
- Plány dotazů s zachycenou zpětnou vazbou LAQ mají řádek s odpovídající plan_id hodnotou v zobrazení katalogu sys.query_store_plan_feedback . Sloupce feature_id a feature_desc jsou nastaveny na 4 a LAQ Feedback.
Pro databázi.
- Zpětná vazba se agreguje pro všechny příkazy, které nemají zpětnou vazbu na úrovni plánu dotazů, například pokud se dotaz nezachytí v úložišti dotazů.
- Zpětná vazba se sleduje od spuštění databáze a po každém spuštění se znovu vytvoří.

Při rozhodování, zda použít LAQ pro dané prohlášení, systém využívá zpětnou vazbu z plánu dotazu, pokud je tato k dispozici. V opačném případě používá zpětnou vazbu na úrovni databáze. To znamená, že některé příkazy se můžou spouštět pomocí LAQ a některé se můžou spouštět bez LAQ. Například LAQ může být pro plán dotazu zakázaný, ale povolený pro databázi a naopak.

Omezení LAQ

Zámek po kvalifikaci se nepoužívá v následujících scénářích:

Pokud je heuristika LAQ zakázaná.
Při použití konfliktních nápověd k uzamčení, například UPDLOCK, READCOMMITTEDLOCK, XLOCK nebo HOLDLOCK.
Pokud je úroveň izolace transakce jiná než READ COMMITTED, nebo pokud je READ_COMMITTED_SNAPSHOT volba databáze zakázaná.
Když se modifikuje tabulka, která má index columnstore.
Když příkaz DML obsahuje přiřazení proměnné.
Když příkaz DML obsahuje OUTPUT klauzuli.
Pokud příkaz DML používá více než jeden operátor hledání indexu nebo prohledávání ke čtení upravované řádky.
V MERGE příkazech.

Změny chování dotazů při použití optimalizovaného uzamykání a RCSI

Souběžné úlohy v rámci izolace čtení potvrzeného snímku (RCSI), které spoléhají na přísné pořadí provádění transakcí, mohou při povolení optimalizovaného uzamčení zaznamenat rozdíly v chování dotazů.

Představte si následující příklad, kdy transakce T2 aktualizuje tabulku t4 na základě sloupce b, který byl aktualizován během transakce T1.

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

INSERT INTO t4
VALUES (1,1);
GO

sezení 1	Sezení 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;`

Vyhodnoťme výsledek předchozího scénáře se zámkem po kvalifikaci i bez něj (LAQ).

bez LAQ

Bez LAQ je příkaz UPDATE v transakci T2 blokován a čeká na dokončení transakce T1. Po dokončení T1 aktualizuje T2 sloupec nastavení řádku b na 3, protože jeho predikát je splněn.

Po potvrzení obou transakcí obsahuje tabulka t4 následující řádky:

 a | b
 1 | 3

s LAQ

U LAQ transakce T2 používá nejnovější potvrzenou verzi řádku, kde se sloupec b rovná 1, k vyhodnocení jeho predikátu (b = 2). Řádek nemá nárok; proto se přeskočí a příkaz se dokončí bez blokování transakce T1. V tomto příkladu LAQ odebere blokování, ale vede k různým výsledkům.

Po potvrzení obou transakcí obsahuje tabulka t4 následující řádky:

 a | b
 1 | 2

Important

I bez LAQ by aplikace neměly předpokládat, že databázový stroj zaručuje přísné řazení bez použití tipů pro uzamčení při použití úrovní izolace založené na verzích řádků. Naším obecným doporučením pro zákazníky, kteří používají souběžné úlohy v rámci RCSI, které spoléhají na striktní pořadí provádění transakcí (jak je znázorněno v předchozím příkladu), je používat přísnější úrovně izolace, jako jsou REPEATABLE READ a SERIALIZABLE.

Diagnostické doplňky pro optimalizované uzamčení

Následující vylepšení vám pomohou monitorovat a řešit problémy s blokováním a záběry, pokud je povoleno optimalizované uzamčení.

Typy čekání pro optimalizované uzamčení
- XACT typy čekání na S zámek v TID a popisy prostředků v sys.dm_os_wait_stats:
  - LCK_M_S_XACT_READ – nastane, když úloha čeká na sdílený zámek u typu XACTwait_resource se záměrem čtení.
  - LCK_M_S_XACT_MODIFY – nastane, když úloha čeká na sdílený zámek typu XACTwait_resource se záměrem upravit.
  - LCK_M_S_XACT – nastane, když úloha čeká na sdílený zámek u typu XACTwait_resource, kde záměr nelze odvodit. Tento scénář není běžný.
Zamknutí viditelnosti zdrojů
- XACT uzamčení prostředků. Další informace najdete v sys.dm_tran_locksresource_description.
Čekání na viditelnost prostředků
- XACT čekačka na prostředky. Další informace najdete v sys.dm_exec_requestswait_resource.
Graf zablokování
- Pod každým prostředkem v sestavě zablokování <resource-list>, každý prvek <xactlock> oznamuje podkladové prostředky a konkrétní informace o zámcích každého účastníka zablokování. Další informace a příklad najdete v tématu Optimalizované uzamčení a zablokování.
Rozšířené události
- Událost lock_after_qual_stmt_abort se aktivuje, když je příkaz interně znovu zpracován kvůli konfliktu s jinou transakcí. Další informace naleznete v tématu Zámek po kvalifikaci (LAQ).
- Událost locking_stats se aktivuje pro každou databázi každých několik minut a poskytuje agregovanou statistiku uzamčení pro časový interval, například počet eskalací zámků, jestli jsou povolené uzamykání TID a komponenty LAQ optimalizovaného uzamčení a počet dotazů, které se z různých důvodů nepoužívaly. Tato událost se aktivuje i v případě, že je vypnuté optimalizované uzamčení.
- V SQL Serveru a službě Azure SQL Managed Instance se událost locking_stats2 aktivuje pro každou databázi každých pár minut a poskytuje statistiky skip index locks a heuristiky LAQ pro daný časový interval.

Osvědčené postupy s optimalizovaným uzamykáním

Povolení izolace potvrzených snímků pro čtení (RCSI)

Pokud chcete maximalizovat výhody optimalizovaného uzamčení, doporučujeme povolit izolaci snímků potvrzených pro čtení (RCSI) v databázi a použít READ COMMITTED izolaci jako výchozí úroveň izolace.

Ve službě Azure SQL Database a SQL Database v Microsoft Fabric je ve výchozím nastavení povoleno RCSI a READ COMMITTED je výchozí úrovní izolace. Když je povoleno RCSI a při použití úrovně izolace READ COMMITTED, procesy čtení čtou verzi řádku z databázového snímku pořízeného na začátku příkazu. V případě LAQ autoři posuzují řádky podle predikátu na základě nejnovější potvrzené verze řádku a bez potřeby získání zámků U. Když používáte LAQ, dotaz počká jenom v případě, že řádek splňuje podmínky a na řádku je aktivní transakce zápisu. Kvalifikace na základě nejnovější potvrzené verze a uzamčení pouze kvalifikovaných řádků snižuje blokování a zvyšuje souběžnost.

Vyhněte se záměrům na zamykání

I když rady pro tabulky a dotazy, jako jsou UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCKatd., jsou při povoleném optimalizovaném uzamčení dodrženy, snižují výhodu optimalizovaného uzamčení. Tzv. lock hinty vynucují, aby databázový engine použil zámky řádků nebo stránek a držel je až do konce transakce, aby respektoval jejich záměr. Některé aplikace mají logiku, kde jsou potřeba zámkové náznaky, například při čtení řádku s náznakem UPDLOCK a jeho následné aktualizaci. Doporučujeme používat pouze nápovědy k uzamčení, jen pokud je to potřeba.

S optimalizovaným uzamčením nejsou žádná omezení stávajících dotazů a dotazy není třeba přepisovat. Dotazy, které nepoužívají nápovědy, nejvíce těží z optimalizovaného uzamykání.

Nápověda k tabulce v jedné tabulce v dotazu nezakáže optimalizované uzamčení pro ostatní tabulky ve stejném dotazu. Optimalizované uzamčení dále ovlivňuje pouze chování uzamčení tabulek, které jsou aktualizovány příkazem DML, jako jsou INSERT, UPDATE, DELETEnebo MERGE. Například:

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;

V předchozím příkladu dotazu se týká zamykání pouze tabulky t6, zatímco tabulka t5 může stále využívat optimalizované zamykání.

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

V předchozím příkladu dotazu používá pouze tabulka t5 úroveň izolace REPEATABLE READ a blokování zámků až do konce transakce. Další aktualizace t5 stále mohou těžit z optimalizovaného uzamčení. Totéž platí pro nápovědu HOLDLOCK.

Nejčastější dotazy

Je ve výchozím nastavení optimalizované uzamčení v nových i existujících databázích?

Ve službě Azure SQL Database, v Azure SQL Managed Instance^AUTD a v databázi SQL v Microsoft Fabric ano. Ve výchozím nastavení je uzamčení optimalizované pro SQL Server 2025 (17.x) zakázané, ale lze ho povolit u jakékoli uživatelské databáze s povoleným akcelerovaným obnovením databáze.

Jak zjistím, jestli je povolené optimalizované uzamčení?

Podívejte se, jestli je povolené optimalizované uzamčení?

Co když chci vynutit blokování dotazů i přes optimalizované uzamčení?

Pokud je povoleno RCSI, použijte nápovědu READCOMMITTEDLOCK tabulky k vynucení blokování mezi dvěma dotazy, když je povoleno optimalizované uzamčení.

Používá se optimalizované uzamčení sekundárních replik jen pro čtení?

Ne, protože příkazy DML nejde spustit na replikách jen pro čtení a odpovídající zámky řádků a stránek se nepřebíjejí.

Používá se optimalizované uzamčení při úpravě dat v databázi tempdb a v dočasných tabulkách?

V tuto chvíli ne.

Průvodce uzamčením transakcí a verzováním řádků
Izolace pomocí potvrzených snímků pro čtení (RCSI)
sys.dm_tran_locks (Transact-SQL)
akcelerované obnovení databáze

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-11-24