XML-indexer (SQL Server)

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

XML-index kan skapas i xml-datatypskolumner. De indexerar alla taggar, värden och sökvägar i XML-instanserna i kolumnen och gynnar frågeprestanda. Ditt program kan dra nytta av ett XML-index i följande situationer:

• Frågor om XML-kolumner är vanliga i din arbetsbelastning. Underhållskostnaden för XML-index under dataändringen måste beaktas.

• DINA XML-värden är relativt stora och de hämtade delarna är relativt små. Genom att skapa indexet undviker man parsning av hela datan vid körtid och gynnar indexsökningar för effektiv frågebearbetning.

Från och med SQL Server 2022 (16.x) och senare versioner, och i Azure SQL Database och Azure SQL Managed Instance kan du använda XML-komprimering för att komprimera XML-data utanför rad för både XML-kolumner och index. XML-komprimering minskar kraven på datalagringskapacitet.

XML-index hamnar i följande kategorier:

• Primärt XML-index
• Sekundärt XML-index

Det första indexet i xml-typkolumnen måste vara det primära XML-indexet. Med det primära XML-indexet stöds följande typer av sekundära index: PATH, VALUE och PROPERTY. Beroende på typen av frågor kan dessa sekundära index hjälpa till att förbättra frågeprestanda.

XML-instanser lagras i xml-typkolumner som stora binära objekt (BLOB). Dessa XML-instanser kan vara stora och den lagrade binära representationen av xml-datatypinstanser kan vara upp till 2 GB. Utan ett index strimlas dessa binära stora objekt vid körning för att utvärdera en förfrågan. Den här fragmentering kan vara tidskrävande. Tänk dig följande fråga:

;WITH XMLNAMESPACES ('https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")

SELECT CatalogDescription.query('
  /PD:ProductDescription/PD:Summary
') as Result
FROM Production.ProductModel
WHERE CatalogDescription.exist ('/PD:ProductDescription/@ProductModelID[.="19"]') = 1;

För att välja XML-instanser som uppfyller villkoret i WHERE-satsen, sönderdelas XML-objektet (BLOB) i varje rad av tabellen Production.ProductModel under körning. Sedan utvärderas uttrycket (/PD:ProductDescription/@ProductModelID[.="19"]) i exist() metoden. Körningstidsdelning kan vara kostsam, beroende på storleken och antalet instanser som lagras i kolumnen.

Om det är vanligt att köra frågor mot XML-binära stora objekt (BLOB) i din programmiljö, hjälper det till att indexera kolumner av XML-typ . Det finns dock en kostnad som är kopplad till att underhålla indexet under dataändringen.

Primärt XML-index

Det primära XML-indexet indexerar alla taggar, värden och sökvägar i XML-instanserna i en XML-kolumn. Om du vill skapa ett primärt XML-index måste tabellen där XML-kolumnen inträffar ha ett grupperat index på den primära nyckeln i tabellen. SQL Server använder den här primärnyckeln för att korrelera rader i det primära XML-indexet med rader i tabellen som innehåller XML-kolumnen.

Det primära XML-indexet är en strimlade och bevarad representation av XML-BLOB:erna i kolumnen xml-datatyp . För varje XML-binärt stort objekt (BLOB) i kolumnen skapar indexet flera rader med data. Antalet rader i indexet är ungefär lika med antalet noder i det stora XML-binära objektet. När en fråga hämtar den fullständiga XML-instansen tillhandahåller SQL Server instansen från XML-kolumnen. Frågor i XML-instanser använder det primära XML-indexet och kan returnera skalära värden eller XML-underträd med hjälp av själva indexet.

Varje rad lagrar följande nodinformation:

• Taggnamn, till exempel ett element eller attributnamn.

• Nodvärde.

• Nodtyp, till exempel en elementnod, en attributnod eller en textnod.

• Dokumentordningsinformation som representeras av en intern nodidentifierare.

• Sökväg från varje nod till XML-trädets rot. I den här kolumnen letas det efter sökvägsuttryck inom frågan.

• Primärnyckel för bastabellen. Bastabellens primära nyckel dupliceras i det primära XML-indexet för en bakåtkoppling med bastabellen, och det maximala antalet kolumner i den primära nyckeln i bastabellen är begränsat till 15.

Den här nodinformationen används för att utvärdera och konstruera XML-resultat för en angiven fråga. I optimeringssyfte kodas taggnamnet och nodtypsinformationen som heltalsvärden, och kolumnen Sökväg använder samma kodning. Dessutom lagras sökvägar i omvänd ordning för att tillåta matchande sökvägar när endast sökvägssuffixet är känt. Till exempel:

• //ContactRecord/PhoneNumber där endast de två sista stegen är kända

ELLER

• /Book/*/Title där jokertecknet * anges i mitten av uttrycket.

Frågeprocessorn använder det primära XML-indexet för frågor som omfattar xml-datatypsmetoder och returnerar antingen skalära värden eller XML-underträd från själva primärindexet. (Det här indexet lagrar all nödvändig information för att rekonstruera XML-instansen.)

Följande fråga returnerar till exempel sammanfattningsinformation som CatalogDescription lagras i kolumnen xml-typ i ProductModel tabellen. Frågan returnerar <Summary> endast information för produktmodeller vars katalogbeskrivning även lagrar beskrivningen <Features> .

;WITH XMLNAMESPACES ('https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")

SELECT CatalogDescription.query('  /PD:ProductDescription/PD:Summary') as Result
FROM Production.ProductModel
WHERE CatalogDescription.exist ('/PD:ProductDescription/PD:Features') = 1

När det gäller det primära XML-indexet genomsöks raderna i indexet som motsvarar varje XML-binärt stort objekt sekventiellt efter det uttryck som anges i metoden i stället för att strimla varje XML-binär stor objektinstans i bastabellen exist() . Om sökvägen hittas i kolumnen Sökväg i indexet hämtas elementet <Summary> tillsammans med dess underträd från det primära XML-indexet och konverteras till ett XML-binärt stort objekt som resultat av query() metoden.

Det primära XML-indexet används inte när du hämtar en fullständig XML-instans. Följande fråga hämtar till exempel hela XML-instansen från tabellen som beskriver tillverkningsinstruktionerna för en specifik produktmodell.

USE AdventureWorks2022;

SELECT Instructions
FROM   Production.ProductModel
WHERE  ProductModelID = 7;

Sekundära XML-index

För att förbättra sökprestandan kan du skapa sekundära XML-index. Ett primärt XML-index måste först finnas innan du kan skapa sekundära index. Det här är typerna:

• PATH-sekundärt XML-index

• VALUE: sekundärt XML-index

• Sekundär XML-index för egenskap

Här följer några riktlinjer för att skapa ett eller flera sekundära index:

• Om din arbetsbelastning använder sökvägsuttryck avsevärt i XML-kolumner kommer det sekundära XML-indexet path sannolikt att påskynda arbetsbelastningen. Det vanligaste fallet är användningen av exist() metoden på XML-kolumner i WHERE-satsen i Transact-SQL.

• Om din arbetsbelastning hämtar flera värden från enskilda XML-instanser med hjälp av sökvägsuttryck kan det vara användbart att gruppera sökvägar inom varje XML-instans i egenskapsindexet. Det här scenariot inträffar vanligtvis i ett egenskapsuppsättningsscenario när egenskaperna för ett objekt hämtas och dess primära nyckelvärde är känt.

• Om din arbetsbelastning innebär att fråga efter värden i XML-instanser utan att känna till element- eller attributnamnen som innehåller dessa värden, kanske du vill skapa VALUE-indexet. Detta inträffar vanligtvis med sökningar på nedåtstigande axlar, till exempel //author[last-name="Howard"], där <author> element kan finnas på vilken nivå som helst i hierarkin. Det förekommer också i wildcard-sökningar, till exempel /book [@* = "novel"], där frågan söker <book> element som har ett attribut med värdet "novel".

PATH-sekundärt XML-index

Om dina frågor vanligtvis anger sökvägsuttryck i xml-typkolumner kan ett sekundärt PATH-index påskynda sökningen. Som beskrivs tidigare i den här artikeln är det primära indexet användbart när du har frågor som anger exist() metoden i WHERE-satsen. Om du lägger till ett sekundärt PATH-index kan du också förbättra sökprestandan i sådana frågor.

Även om ett primärt XML-index undviker att behöva strimlade xml-binära stora objekt vid körning, kanske det inte ger den bästa prestandan för frågor baserat på sökvägsuttryck. Eftersom alla rader i det primära XML-indexet som motsvarar ett xml-binärt stort objekt genomsöks sekventiellt efter stora XML-instanser kan sekventiell sökning vara långsam. I det här fallet kan ett sekundärt index som bygger på sökvägsvärdena och nodvärdena i det primära indexet avsevärt påskynda indexsökningen. I det sekundära PATH-indexet är sökvägen och nodvärdena nyckelkolumner som möjliggör effektivare sökningar när du söker efter sökvägar. Frågeoptimeraren kan använda PATH-indexet för uttryck som de som visas i följande:

• /root/Location som endast anger en sökväg

ELLER

• /root/Location/@LocationID[.="10"] där både sökvägen och nodvärdet anges.

Följande fråga visar var PATH-indexet är användbart:

;WITH XMLNAMESPACES ('https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")

SELECT CatalogDescription.query('
  /PD:ProductDescription/PD:Summary
') AS Result
FROM Production.ProductModel
WHERE CatalogDescription.exist ('/PD:ProductDescription/@ProductModelID[.="19"]') = 1;

I frågan motsvarar sökvägsuttrycket /PD:ProductDescription/@ProductModelID och värdet "19" i exist() metoden nyckelfälten i PATH-indexet. Detta möjliggör direkt sökning i PATH-indexet och ger bättre sökprestanda än sekventiell sökning efter sökvägsvärden i det primära indexet.

VALUE: sekundärt XML-index

Om frågor är värdebaserade, /Root/ProductDescription/@*[. = "Mountain Bike"] till exempel eller //ProductDescription[@Name = "Mountain Bike"], och sökvägen inte är helt angiven eller om den innehåller ett jokertecken, kan du få snabbare resultat genom att skapa ett sekundärt XML-index som bygger på nodvärden i det primära XML-indexet.

Nyckelkolumnerna i VALUE-indexet är (nodvärde och sökväg) för det primära XML-indexet. Om din arbetsbelastning innebär att fråga efter värden från XML-instanser utan att känna till element- eller attributnamnen som innehåller värdena, kan ett VALUE-index vara användbart. Följande uttryck drar till exempel nytta av att ha ett VALUE-index:

• //author[LastName="someName"] där du vet värdet för elementet <LastName> , men den <author> överordnade kan inträffa var som helst.

• /book[@* = "someValue"] där frågan letar efter elementet <book> som har ett attribut med värdet "someValue".

Följande fråga returnerar ContactID från Contact tabellen. Satsen WHERE anger ett filter som söker efter värden i AdditionalContactInfokolumnen xml-typ . Kontakt-ID:t returneras endast om motsvarande ytterligare kontaktuppgifter XML binära stora objekt innehåller ett visst telefonnummer. Eftersom elementet telephoneNumber kan visas var som helst i XML anger sökvägsuttrycket den underordnade axeln eller självaxeln.

;WITH XMLNAMESPACES (
  'https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ContactInfo' AS CI,
  'https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ContactTypes' AS ACT
)

SELECT ContactID
FROM Person.Contact
WHERE AdditionalContactInfo.exist('//ACT:telephoneNumber/ACT:number[.="111-111-1111"]') = 1;

I den här situationen är sökvärdet <number> känt, men det kan visas var som helst i XML-instansen som ett barn av elementet telephoneNumber. Den här typen av fråga kan dra nytta av ett indexuppslag baserat på ett specifikt värde.

SEKUNDÄRT EGENSKAPSINDEX

Frågor som hämtar ett eller flera värden från enskilda XML-instanser kan dra nytta av ett EGENSKAPsindex. Det här scenariot inträffar när du hämtar objektegenskaper med hjälp value() av metoden för xml-typen och när objektets primära nyckelvärde är känt.

EGENSKAPsindexet bygger på kolumner (PK, sökväg och nodvärde) för det primära XML-indexet där PK är den primära nyckeln i bastabellen.

För produktmodellen 19hämtar till exempel följande fråga attributvärdena ProductModelID och ProductModelName med metoden value() . I stället för att använda det primära XML-indexet eller andra sekundära XML-index kan EGENSKAPsindexet ge snabbare körning.

;WITH XMLNAMESPACES ('https://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")

SELECT CatalogDescription.value('(/PD:ProductDescription/@ProductModelID)[1]', 'int') AS ModelID,
  CatalogDescription.value('(/PD:ProductDescription/@ProductModelName)[1]', 'varchar(30)') AS ModelName
FROM Production.ProductModel
WHERE ProductModelID = 19;

Förutom de skillnader som beskrivs senare i den här artikeln liknar skapandet av ett XML-index för en xml-typkolumn att skapa ett index för en kolumn av typen icke-XML . Följande Transact-SQL DDL-instruktioner kan användas för att skapa och hantera XML-index:

• SKAPA INDEX (Transact-SQL)
• ALTER INDEX (Transact-SQL)
• DROP-INDEX (Transact-SQL)

XML-komprimering

gäller för: SQL Server 2022 (16.x) och senare versioner, Azure SQL Database och Azure SQL Managed Instance.

När XML-komprimering aktiveras ändras det fysiska lagringsformatet för de data som är associerade med XML-datatypen till ett komprimerat binärt format, men ändrar inte XML-datasyntaxen eller semantiken. Programändringar krävs inte när en eller flera tabeller är aktiverade för XML-komprimering.

Endast XML-datatypen påverkas av XML-komprimering. XML-data komprimeras med Xpress-komprimeringsalgoritmen. Befintliga XML-index komprimeras med hjälp av datakomprimering. Datakomprimering aktiveras internt för XML-index när XML-komprimering är aktiverat.

XML-komprimering kan aktiveras sida vid sida med datakomprimering i samma tabeller.

XML-index ärver inte komprimeringsegenskapen för tabellen. Om du vill komprimera index måste du uttryckligen aktivera XML-komprimering på XML-index.

Sekundära XML-index ärver inte komprimeringsegenskapen för det primära XML-indexet.

Som standard är XML-komprimeringsinställningen för XML-index inställd på AV när indexet skapas.

Hämta information om XML-index

XML-indexposter visas i katalogvyn sys.indexes med indexet type3för . Namnkolumnen innehåller namnet på XML-indexet.

XML-index registreras också i katalogvyn sys.xml_indexes. Detta innehåller alla kolumner sys.indexes i och några specifika kolumner som är användbara för XML-index. Värdet NULL i kolumnen secondary_type anger ett primärt XML-index, värdena PR och V står för PATH, PROPERTY respektive VALUE secondary XML-index.

Utrymmesanvändningen för XML-index kan hittas i den tabellvärda funktionen sys.dm_db_index_physical_stats. Den innehåller information, till exempel antalet upptagna datasidor, genomsnittlig radstorlek i byte och antal poster för alla indextyper. Detta inkluderar även XML-index. Den här informationen är tillgänglig för varje databaspartition. XML-index använder samma partitioneringsschema och partitioneringsfunktion i bastabellen.

Nästa steg

• Skapa XML-index
• ALTER INDEX (selektiva XML-index)
• sys.dm_db_index_physical_stats (Transact-SQL)
• XML-data (SQL Server)