Hvordan filtrerede indekser kunne være en mere kraftfuld funktion

Så til enhver tid kan der kun eksistere én NULL-værdi i denne kolonne. I modsætning til de fleste scenarier er dette et tilfælde, hvor SQL Server behandler to NULL-værdier som lige (i stedet for at bestemme, at lighed simpelthen er ukendt og til gengæld falsk). Folk har klaget over denne inkonsekvens i årevis.

Hvis dette er et krav, kan vi nu omgå dette ved hjælp af filtrerede indekser:

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

Nu fungerer vores 4. insert fint, da unikhed kun håndhæves på de ikke-NULL-værdier. Dette er en slags snyd, men det opfylder de grundlæggende krav, som ANSI-standarden havde til hensigt (selvom SQL Server ikke tillader os at bruge ALTER TABLE ... ADD CONSTRAINT syntaks for at skabe en filtreret unik begrænsning).

Men hold telefonen

Dette er gode eksempler på, hvad vi kan gøre med filtrerede indekser, men der er mange ting, vi stadig ikke kan gøre, og flere begrænsninger og problemer, der dukker op som et resultat.

Statistikopdateringer

Dette er en af ​​de vigtigere begrænsninger IMHO. Filtrerede indekser drager ikke fordel af automatisk opdatering af statistik baseret på en procentvis ændring af undergruppen af ​​tabellen, der identificeres af filterprædikatet; den er baseret (som alle ikke-filtrerede indekser) på churn mod hele tabellen. Det betyder, at afhængigt af hvor stor en procentdel af tabellen der er i det filtrerede indeks, kan antallet af rækker i indekset firdobles eller halveres, og statistikken opdateres ikke, medmindre du gør det manuelt. Kimberly Tripp har givet nogle gode oplysninger om dette (og Gail Shaw nævner et eksempel, hvor det tog 257.000 opdateringer, før statistikker blev opdateret for et filtreret indeks, der kun indeholdt 10.000 rækker):

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

Kimberlys kollega, Joe Sack (@JosephSack), har også indsendt et Connect-element, der foreslår at korrigere denne adfærd for både filtrerede indekser og filtrerede statistikker.

Filter udtryksbegrænsninger

Der er flere konstruktioner, du ikke kan bruge i et filterprædikat, såsom NOT IN , OR og dynamiske/ikke-deterministiske prædikater som WHERE col >= DATEADD(DAY, -1, GETDATE()) . Desuden genkender optimeringsværktøjet muligvis ikke et filtreret indeks, hvis prædikatet ikke nøjagtigt matcher WHERE klausul i indeksdefinitionen. Her er et par Connect-elementer, der prøver at lokke noget støtte til bedre dækning her:

Andre potentielle anvendelser er i øjeblikket ikke mulige

Vi kan i øjeblikket ikke oprette et filtreret indeks på en vedvarende beregnet kolonne, selvom det er deterministisk. Vi kan ikke pege en fremmednøgle mod et unikt filtreret indeks; hvis vi ønsker, at et indeks skal understøtte fremmednøglen ud over de forespørgsler, der understøttes af det filtrerede indeks, skal vi oprette et andet, redundant, ikke-filtreret indeks. Og her er et par andre lignende begrænsninger, som enten er blevet overset eller ikke overvejet endnu:

Problemer med MERGE

Og MERGE optræder endnu en gang på min "pas på"-liste:

Mens en af ​​disse (tilsyneladende nært beslægtede) fejl siger, at den er rettet i SQL Server 2012, er du muligvis nødt til at kontakte PSS, hvis du støder på en variation af dette problem, især på tidligere versioner (eller stoppe med at bruge MERGE , som jeg har foreslået før).

Værktøj / DMV / indbyggede begrænsninger

Der er mange DMV'er, DBCC-kommandoer, systemprocedurer og klientværktøjer, som vi begynder at stole på med tiden. Det er dog ikke alle disse ting, der er opdateret for at drage fordel af nye funktioner; filtrerede indekser er ingen undtagelse. Følgende Connect-elementer påpeger nogle problemer, der kan gøre dig gal, hvis du forventer, at de skal fungere med filtrerede indekser:

For de sidste tre, hold ikke vejret – det er usandsynligt, at Microsoft på noget tidspunkt investerer i sp_-procedurerne, DMV'er, INFORMATION_SCHEMA-visninger osv. Se i stedet Kimberly Tripps sp_helpindex-omskrivninger, som inkluderer information om filtrerede indekser langs med andre nye funktioner, som Microsoft har efterladt.

Optimeringsværktøjets begrænsninger

Der er flere Connect-elementer, der beskriver tilfælde, hvor filtrerede indekser *kunne* bruges af optimeringsværktøjet, men i stedet ignoreres. I nogle tilfælde betragtes disse ikke som "bugs", men snarere "mangler i funktionalitet"...

Paul White (@SQL_Kiwi) postede for nylig her på SQLPerformance.com et indlæg, der går i detaljer om et par af ovenstående optimeringsbegrænsninger.

Og Tim Chapman skrev et godt indlæg, der skitserede nogle andre begrænsninger af filtrerede indekser – såsom manglende evne til at matche prædikatet til en lokal variabel (fastsat i 2008 R2 SP1) og manglende evne til at specificere et filtreret indeks i et indekstip.

Konklusion

Filtrerede indekser har et stort potentiale, og jeg havde ekstremt store forhåbninger til dem, da de først blev introduceret i SQL Server 2008. De fleste af de begrænsninger, der fulgte med deres første version, eksisterer dog stadig i dag, halvanden (eller to, afhængigt af din perspektiv) større udgivelser senere. Ovenstående virker som en ret omfattende vasketøjsliste over ting, der skal løses, men jeg mente ikke, at det skulle komme over på den måde. Jeg vil bare have, at folk skal være opmærksomme på det store antal potentielle problemer, de muligvis skal overveje, når de udnytter filtrerede indekser.