Hoe gefilterde indexen een krachtigere functie kunnen zijn

Er kan dus altijd maar één NULL-waarde in deze kolom staan. In tegenstelling tot de meeste scenario's is dit een geval waarin SQL Server twee NULL-waarden als gelijk behandelt (in plaats van te bepalen dat gelijkheid simpelweg onbekend is en op zijn beurt onwaar). Mensen klagen al jaren over deze inconsistentie.

Als dit een vereiste is, kunnen we dit nu omzeilen met behulp van gefilterde indexen:

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

Nu werkt onze 4e invoeging prima, omdat uniciteit alleen wordt afgedwongen op de niet-NULL-waarden. Dit is een beetje vals spelen, maar het voldoet wel aan de basisvereisten die de ANSI-standaard bedoeld heeft (ook al staat SQL Server ons niet toe om ALTER TABLE ... ADD CONSTRAINT te gebruiken syntaxis om een ​​gefilterde unieke beperking te maken).

Maar houd de telefoon vast

Dit zijn geweldige voorbeelden van wat we kunnen doen met gefilterde indexen, maar er zijn veel dingen die we nog steeds niet kunnen doen, met als gevolg verschillende beperkingen en problemen.

Statistische updates

Dit is een van de belangrijkste beperkingen IMHO. Gefilterde indexen profiteren niet van het automatisch bijwerken van statistieken op basis van een procentuele verandering van de subset van de tabel die wordt geïdentificeerd door het filterpredikaat; het is gebaseerd (zoals alle niet-gefilterde indexen) op verloop ten opzichte van de hele tabel. Dit betekent dat, afhankelijk van welk percentage van de tabel zich in de gefilterde index bevindt, het aantal rijen in de index kan verviervoudigen of halveren en dat de statistieken niet worden bijgewerkt, tenzij u dit handmatig doet. Kimberly Tripp heeft hier geweldige informatie over gegeven (en Gail Shaw noemt een voorbeeld waarbij er 257.000 updates nodig waren voordat de statistieken werden bijgewerkt voor een gefilterde index die slechts 10.000 rijen bevatte):

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/

Ook heeft Kimberly's collega, Joe Sack (@JosephSack), een Connect-item ingediend waarin wordt voorgesteld dit gedrag te corrigeren voor zowel gefilterde indexen als gefilterde statistieken.

Uitdrukkingsbeperkingen filteren

Er zijn verschillende constructies die u niet kunt gebruiken in een filterpredikaat, zoals NOT IN , OR en dynamische / niet-deterministische predikaten zoals WHERE col >= DATEADD(DAY, -1, GETDATE()) . Het is ook mogelijk dat de optimizer een gefilterde index niet herkent als het predikaat niet exact overeenkomt met de WHERE clausule in de indexdefinitie. Hier zijn een paar Connect-items die hier enige ondersteuning proberen te krijgen voor een betere dekking:

Andere mogelijke toepassingen momenteel niet mogelijk

We kunnen momenteel geen gefilterde index maken voor een persistente berekende kolom, zelfs niet als deze deterministisch is. We kunnen een externe sleutel niet naar een unieke gefilterde index verwijzen; als we willen dat een index de externe sleutel ondersteunt naast de query's die door de gefilterde index worden ondersteund, moeten we een tweede, redundante, niet-gefilterde index maken. En hier zijn een paar andere soortgelijke beperkingen die over het hoofd zijn gezien of nog niet zijn overwogen:

Problemen met MERGE

En MERGE maakt weer een verschijning op mijn "let op" lijst:

Hoewel een van deze (schijnbaar nauw verwante) bugs zegt dat het is opgelost in SQL Server 2012, moet je mogelijk contact opnemen met PSS als je een variatie op dit probleem tegenkomt, met name bij eerdere versies (of stop met het gebruik van MERGE , zoals ik eerder heb voorgesteld).

Tool / DMV / ingebouwde beperkingen

Er zijn veel DMV's, DBCC-opdrachten, systeemprocedures en clienttools waarop we na verloop van tijd beginnen te vertrouwen. Niet al deze dingen worden echter bijgewerkt om te profiteren van nieuwe functies; gefilterde indexen zijn geen uitzondering. De volgende Connect-items wijzen op enkele problemen die u kunnen laten struikelen als u verwacht dat ze werken met gefilterde indexen:

Voor de laatste drie, houd je adem niet in - Microsoft zal waarschijnlijk geen tijd investeren in de sp_-procedures, DMV's, INFORMATION_SCHEMA-weergaven, enz. Bekijk in plaats daarvan Kimberly Tripp's sp_helpindex-herschrijvingen, die informatie bevatten over gefilterde indexen met andere nieuwe functies die Microsoft heeft achtergelaten.

Optimizerbeperkingen

Er zijn verschillende Connect-items die gevallen beschrijven waarin gefilterde indexen *kunnen* worden gebruikt door de optimizer, maar in plaats daarvan worden genegeerd. In sommige gevallen worden deze niet als "bugs" beschouwd, maar eerder als "lacunes in functionaliteit"…

Paul White (@SQL_Kiwi) plaatste onlangs hier op SQLPerformance.com een ​​bericht dat uitgebreid ingaat op een aantal van de bovenstaande optimalisatiebeperkingen.

En Tim Chapman schreef een geweldige post waarin hij enkele andere beperkingen van gefilterde indexen uiteenzette - zoals het onvermogen om het predikaat te matchen met een lokale variabele (vastgesteld in 2008 R2 SP1) en het onvermogen om een ​​gefilterde index op te geven in een indexhint.

Conclusie

Gefilterde indexen hebben een groot potentieel en ik had er zeer hoge verwachtingen van toen ze voor het eerst werden geïntroduceerd in SQL Server 2008. De meeste beperkingen die bij hun eerste versie werden geleverd, bestaan ​​echter nog steeds, anderhalf (of twee, afhankelijk van uw perspectief) grote releases later. Bovenstaande lijkt een behoorlijk uitgebreide waslijst van zaken die aangepakt moeten worden, maar het was niet mijn bedoeling dat het zo over zou komen. Ik wil gewoon dat mensen zich bewust zijn van het enorme aantal potentiële problemen waarmee ze rekening moeten houden wanneer ze profiteren van gefilterde indexen.