Doporučuji vám projít si Používání tabulek jako front. Správně implementované fronty dokážou zpracovat tisíce souběžných uživatelů a obsluhovat až 1/2 milionu operací fronty/dequeue za minutu. Až do SQL Server 2005 bylo řešení těžkopádné a zahrnovalo kombinaci SELECT
a UPDATE
v jediné transakci a poskytněte správnou kombinaci tipů na uzamčení, jako v článku, na který odkazuje gbn. Naštěstí od SQL Server 2005 s příchodem klauzule OUTPUT je k dispozici mnohem elegantnější řešení a MSDN nyní doporučuje používat klauzuli OUTPUT:
OUTPUT můžete použít v aplikacích, které používají tabulky jako fronty, nebo k udržení mezilehlých sad výsledků. To znamená, že aplikace neustále přidává nebo odebírá řádky z tabulky
V zásadě existují 3 části skládačky, které musíte správně nastavit, aby to fungovalo vysoce souběžným způsobem:
- Je třeba automaticky vyřadit z fronty. Musíte najít řádek, přeskočit všechny zamknuté řádky a označit jej jako „vyřazený z fronty“ v jediné atomické operaci, a zde je
OUTPUT
do hry vstupuje klauzule:
with CTE as (
SELECT TOP(1) COMMAND, PROCESSED
FROM TABLE WITH (READPAST)
WHERE PROCESSED = 0)
UPDATE CTE
SET PROCESSED = 1
OUTPUT INSERTED.*;
- Musíte strukturujte tabulku pomocí indexového klíče seskupeného nejvíce vlevo na
PROCESSED
sloupec. PokudID
byl použit primární klíč, poté jej přesuňte jako druhý sloupec v seskupeném klíči. Debata o tom, zda ponechat neseskupený klíč naID
sloupec je otevřený, ale důrazně upřednostňuji ne mající jakékoli sekundární indexy bez klastrů ve frontách:
CREATE CLUSTERED INDEX cdxTable on TABLE(PROCESSED, ID);
- Na tuto tabulku se nesmíte dotazovat žádným jiným způsobem než vyřazením z fronty. Pokoušíte se provádět operace Peek nebo se pokoušíte použít tabulku jako frontu a jako obchod velmi pravděpodobně vést k uváznutí a dramaticky zpomalit propustnost.
Kombinace atomické dequeue, READPAST nápověda pro vyhledávání prvků k dequeue a klíč zcela vlevo na seskupeném indexu na základě bitu zpracování zajišťují velmi vysokou propustnost při vysoce souběžném zatížení.