Hur filtrerade index kan vara en mer kraftfull funktion

Så när som helst kan bara ett NULL-värde finnas i den här kolumnen. Till skillnad från de flesta scenarier är detta ett fall där SQL Server behandlar två NULL-värden som lika (istället för att fastställa att likhet helt enkelt är okänd och i sin tur falsk). Folk har klagat över denna inkonsekvens i flera år.

Om detta är ett krav kan vi nu kringgå detta med filtrerade index:

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

Nu fungerar vår 4:e insättning alldeles utmärkt, eftersom unikhet endast framtvingas på icke-NULL-värden. Detta är ett slags fusk, men det uppfyller de grundläggande kraven som ANSI-standarden avsåg (även om SQL Server inte tillåter oss att använda ALTER TABLE ... ADD CONSTRAINT syntax för att skapa en filtrerad unik begränsning).

Men håll i telefonen

Det här är bra exempel på vad vi kan göra med filtrerade index, men det finns många saker vi fortfarande inte kan göra, och flera begränsningar och problem som kommer upp som ett resultat.

Statistikuppdateringar

Detta är en av de viktigare begränsningarna IMHO. Filtrerade index gynnas inte av automatisk uppdatering av statistik baserat på en procentuell förändring av den delmängd av tabellen som identifieras av filterpredikatet; den är baserad (som alla icke-filtrerade index) på churn mot hela tabellen. Det betyder att, beroende på hur stor andel av tabellen som finns i det filtrerade indexet, kan antalet rader i indexet fyrdubblas eller halveras och statistiken kommer inte att uppdateras om du inte gör det manuellt. Kimberly Tripp har gett bra information om detta (och Gail Shaw nämner ett exempel där det tog 257 000 uppdateringar innan statistiken uppdaterades för ett filtrerat index som bara innehöll 10 000 rader):

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/

Dessutom har Kimberlys kollega, Joe Sack (@JosephSack), skickat in ett Connect-objekt som föreslår att man korrigerar detta beteende för både filtrerade index och filtrerad statistik.

Begränsningar för filteruttryck

Det finns flera konstruktioner som du inte kan använda i ett filterpredikat, till exempel NOT IN , OR och dynamiska/icke-deterministiska predikat som WHERE col >= DATEADD(DAY, -1, GETDATE()) . Dessutom kanske optimeraren inte känner igen ett filtrerat index om predikatet inte exakt matchar WHERE klausul i indexdefinitionen. Här är några Connect-objekt som försöker locka till sig lite stöd för bättre täckning här:

Andra potentiella användningsområden är för närvarande inte möjliga

Vi kan för närvarande inte skapa ett filtrerat index på en beständig beräknad kolumn, även om den är deterministisk. Vi kan inte peka en främmande nyckel mot ett unikt filtrerat index; om vi vill att ett index ska stödja den främmande nyckeln utöver de frågor som stöds av det filtrerade indexet, måste vi skapa ett andra, redundant, icke-filtrerat index. Och här är några andra liknande begränsningar som antingen har förbisetts eller inte har beaktats ännu:

Problem med MERGE

Och MERGE gör ännu ett framträdande på min "se upp"-lista:

Medan en av dessa (till synes närbesläktade) buggar säger att det är fixat i SQL Server 2012, kan du behöva kontakta PSS om du stöter på någon variant av det här problemet, särskilt på tidigare versioner (eller sluta använda MERGE , som jag har föreslagit tidigare).

Begränsningar för verktyg / DMV / inbyggda

Det finns många DMV, DBCC-kommandon, systemprocedurer och klientverktyg som vi börjar lita på med tiden. Men alla dessa saker uppdateras inte för att dra nytta av nya funktioner; filtrerade index är inget undantag. Följande Connect-objekt pekar på några problem som kan göra dig snurrig om du förväntar dig att de ska fungera med filtrerade index:

För de tre sista, håll inte andan – Microsoft kommer sannolikt inte att investera någon gång i sp_-procedurerna, DMV:er, INFORMATION_SCHEMA-vyer etc. Se istället Kimberly Tripps sp_helpindex-omskrivningar, som inkluderar information om filtrerade index längs med andra nya funktioner som Microsoft har lämnat bakom sig.

Optimerarens begränsningar

Det finns flera Connect-objekt som beskriver fall där filtrerade index *kan* användas av optimeraren, men istället ignoreras. I vissa fall betraktas dessa inte som "buggar" utan snarare "luckor i funktionalitet"...

Paul White (@SQL_Kiwi) postade nyligen här på SQLPerformance.com ett inlägg som går in i detalj om ett par av ovanstående optimeringsbegränsningar.

Och Tim Chapman skrev ett bra inlägg som beskriver några andra begränsningar för filtrerade index – som oförmågan att matcha predikatet med en lokal variabel (fixad i 2008 R2 SP1) och oförmågan att specificera ett filtrerat index i en indextips.

Slutsats

Filtrerade index har stor potential och jag hade extremt höga förhoppningar på dem när de först introducerades i SQL Server 2008. Men de flesta begränsningarna som levererades med deras första version existerar fortfarande idag, en och en halv (eller två, beroende på din perspektiv) större utgåvor senare. Ovanstående verkar vara en ganska omfattande tvättlista med saker som måste åtgärdas, men jag menade inte att det skulle komma fram på det sättet. Jag vill bara att folk ska vara medvetna om det stora antalet potentiella problem de kan behöva tänka på när de utnyttjar filtrerade index.