Jak by filtrované indexy mohly být výkonnější funkcí

V každém okamžiku tedy může v tomto sloupci existovat pouze jedna hodnota NULL. Na rozdíl od většiny scénářů se jedná o jeden případ, kdy SQL Server považuje dvě hodnoty NULL za stejné (spíše než určení, že rovnost je jednoduše neznámá a naopak nepravdivá). Lidé si na tuto nekonzistenci stěžují již léta.

Pokud je to požadavek, můžeme to nyní obejít pomocí filtrovaných indexů:

ALTER TABLE dbo.Personnel DROP CONSTRAINT UQ_SSN;
GO
 
CREATE UNIQUE INDEX UQ_SSN ON dbo.Personnel(SSN)
  WHERE SSN IS NOT NULL;

Nyní naše 4. vložka funguje dobře, protože jedinečnost je vynucena pouze u hodnot, které nejsou NULL. Toto je druh podvádění, ale splňuje základní požadavky, které zamýšlel standard ANSI (i když nám SQL Server neumožňuje použít ALTER TABLE ... ADD CONSTRAINT syntaxe k vytvoření filtrovaného jedinečného omezení).

Ale podržte telefon

Toto jsou skvělé příklady toho, co můžeme dělat s filtrovanými indexy, ale existuje mnoho věcí, které stále neumíme, a několik omezení a problémů, které z toho vyplývají.

Aktualizace statistik

Toto je IMHO jedno z nejdůležitějších omezení. Filtrované indexy nemají prospěch z automatické aktualizace statistik na základě procentuální změny podmnožiny tabulky, která je identifikována predikátem filtru; je založen (jako všechny nefiltrované indexy) na churn proti celé tabulce. To znamená, že v závislosti na tom, jaké procento tabulky je ve filtrovaném indexu, se počet řádků v indexu může zčtyřnásobit nebo snížit na polovinu a statistiky se neaktualizují, pokud to neuděláte ručně. Kimberly Tripp o tom poskytla několik skvělých informací (a Gail Shaw uvádí příklad, kdy trvalo 257 000 aktualizací, než byly aktualizovány statistiky pro filtrovaný index, který obsahoval pouze 10 000 řádků):

https://www.sqlskills.com/blogs/kimberly/filtered-indexes-and-filtered-stats-might-become-seriously-out-of-date/
https://www.sqlskills.com/ blogs/kimberly/category/filtered-indexes/

Také Kimberlyin kolega, Joe Sack (@JosephSack), zadal položku Connect, která navrhuje opravit toto chování pro filtrované indexy i filtrované statistiky.

Omezení výrazu filtru

Existuje několik konstrukcí, které nemůžete použít v predikátu filtru, například NOT IN , OR a dynamické / nedeterministické predikáty jako WHERE col >= DATEADD(DAY, -1, GETDATE()) . Optimalizátor také nemusí rozpoznat filtrovaný index, pokud predikát přesně neodpovídá WHERE klauzule v definici indexu. Zde je několik položek Connect, které se zde snaží získat podporu pro lepší pokrytí:

Další potenciální využití v současné době není možné

V současné době nemůžeme vytvořit filtrovaný index na trvalém vypočítaném sloupci, i když je deterministický. Nemůžeme nasměrovat cizí klíč na jedinečný filtrovaný index; pokud chceme, aby index podporoval cizí klíč navíc k dotazům podporovaným filtrovaným indexem, musíme vytvořit druhý, redundantní, nefiltrovaný index. A zde je několik dalších podobných omezení, která byla buď přehlížena, nebo dosud nebyla brána v úvahu:

Problémy s MERGE

A MERGE se znovu objeví na mém seznamu „pozor na to:

I když jedna z těchto (zdánlivě úzce souvisejících) chyb říká, že je opravena v SQL Server 2012, možná budete muset kontaktovat PSS, pokud narazíte na jakoukoli variantu tohoto problému, zejména v dřívějších verzích (nebo přestaňte používat MERGE , jak jsem již naznačil).

Omezení nástrojů / DMV / vestavěných

Existuje mnoho DMV, DBCC příkazů, systémových procedur a klientských nástrojů, na které se postupem času začínáme spoléhat. Ne všechny tyto věci jsou však aktualizovány, aby mohly využívat nové funkce; filtrované indexy nejsou výjimkou. Následující položky Connectu upozorňují na některé problémy, které vás mohou podrazit, pokud očekáváte, že budou pracovat s filtrovanými indexy:

U posledních tří nezadržujte dech – je nepravděpodobné, že by Microsoft investoval čas do procedur sp_, DMV, zobrazení INFORMATION_SCHEMA atd. Místo toho se podívejte na přepisy sp_helpindex od Kimberly Tripp, které obsahují informace o filtrovaných indexech s dalšími novými funkcemi, které Microsoft zanechal.

Omezení Optimalizátoru

Existuje několik položek Connect, které popisují případy, kdy filtrované indexy *mohl* použít optimalizátor, ale místo toho jsou ignorovány. V některých případech nejsou považovány za „chyby“, ale spíše za „mezery ve funkčnosti“…

Paul White (@SQL_Kiwi) nedávno zveřejnil zde na SQLPerformance.com příspěvek, který velmi podrobně popisuje několik výše uvedených omezení optimalizátoru.

A Tim Chapman napsal skvělý příspěvek, který nastínil některá další omezení filtrovaných indexů – například nemožnost spárovat predikát s lokální proměnnou (opraveno v 2008 R2 SP1) a nemožnost specifikovat filtrovaný index v nápovědě k indexu.

Závěr

Filtrované indexy mají velký potenciál a vkládal jsem do nich extrémně velké naděje, když byly poprvé představeny v SQL Server 2008. Většina omezení dodávaných s jejich první verzí však stále existuje dodnes, jeden a půl (nebo dvě, v závislosti na vaší perspektiva) hlavní verze později. Výše uvedené vypadá jako docela obsáhlý seznam položek, které je třeba řešit, ale neměl jsem v úmyslu, aby to tak bylo. Chci jen, aby si lidé byli vědomi obrovského množství potenciálních problémů, které mohou potřebovat zvážit, když využívají filtrované indexy.