Skip to main content

XML Index in SQL server

XML Index
An XML index is designed to handle indexing XML type column and has been available since SQL Server 2005. Many organizations store and transmit their data in XML format. We know XML is very convenient and popular to consume and provide the data that is the reason SQL server team worked on this and increased the performance of XML query using XML Indexing. When these indexes are used properly, they can dramatically reduce execution time in queries made against XML columns.

Why XML Index
When an index does not exist, an XML field must be 'shred' when the query is executed. This means that XML data is separated from XML tags, and is arranged in a relational format. An XML index works before time, represents XML data in the already-shredded version, allowing easy filtering.

You must know some XML Index Ground Rules
The XML index can only be applied to XML data type columns. To use the XML index on a specific table, there should be a cluster index on the primary key column in the table
Note: a primary key constraint includes a clustered index upon creation by default.
There are two types of XML indexes, first is Primary and second is Secondary.
A primary XML index essentially contains one row of information for each node in the XML column. This information is made up of XML node values, types, and paths. A primary index is a ‘pre-shredded’ representation of the XML blob – an easy-to-filter copy of the XML data.
Secondary XML indexes are dependent on primary XML indexes – you cannot create any secondary indexes without first having created a primary index.
Secondary XML indexes come in 3 types: PATH, VALUE, and PROPERTY indexes. Secondary indexes are designed to provide additional optimization for certain types of XML queries.
1-     PATH secondary indexes often help to optimize queries that make use of a path. An exist() method in the query usually indicates that a PATH index may improve the query execution.
2-     PROPERTY secondary indexes are designed to be helpful with queries where the primary key field is used, and where multiple values are retrieved from a single XML instance.
3-    VALUE secondary indexes are good for queries that use wildcards in a path to find known values – if the full path is not known, but the value being filtered IS known, a VALUE index will probably optimize the query execution.
How to create XML Index
As we know, primary key column and clustered index is mandatory to create an XML index so we have to create clustered index first. Using the following index we can create the XML index.

CREATE TABLE Product.Inventory (ID INT PRIMARY KEY, XmlDetails XML); 
-- Create primary index. 
CREATE PRIMARY XML INDEX PIdx_Inventory_XmlDetails  
ON T(XmlCol); 
-- Create secondary indexes (PATH, VALUE, PROPERTY). 
CREATE XML INDEX PIdx_Inventory_XmlDetails_PATH ON T(XmlDetails) 
USING XML INDEX PIdx_Inventory_XmlDetails 
CREATE XML INDEX PIdx_T_XmlDetails_VALUE ON T(XmlDetails) 
USING XML INDEX PIdx_Inventory_XmlDetails 
CREATE XML INDEX PIdx_Inventory_XmlDetails_PROPERTY ON T(XmlDetails) 
USING XML INDEX PIdx_Inventory_XmlDetails 

In above example, suppose we have a table Inventory which contains all information if your product and XML columns which has all information like Product details, SKU, ISBN etc. in XML format if we want to increase the XML query performance then we need indexing of this column using above script.

Popular posts from this blog

Check for changes to an SQL Server table?

Problem: Suppose your team is working on the under-development project so it might be possible continuous work on the database and perform changes in Table, Stored procedure as per requirement, and daily you have to update the testing server database as per changes are done in developing server database then how it is possible to trace those changes. There are a lot of solutions for this problem which is listed below Solution 1: For SQL Server 2000, 2005 and above use the CHECKSUM command SELECTCHECKSUM_AGG(BINARY_CHECKSUM(*))FROMYour_Table_NameWITH (NOLOCK); That will return the same number each time its run as long as the table contents haven't changed. Unfortunately CHECKSUM does not work always properly to detect changes. It is only a primitive checksum and no CRC calculation. Therefore you can't use it to detect all changes, e. g. symmetrical changes result in the same CHECKSUM! Solution 2: 1.Run the following query. Before executing query replace DB_Name with your database name…

Merge and Merge join transformation in SSIS

How to drop multiple tables with common prefix in one query?

Problem: Suppose we have a situation where we need to drop those tables that have some prefixes string, so it is possible to drop those tables with a common prefix in a single query.
Solution: yes it is possible to drop all those tables that have the common prefix in a single query. Using following query you can delete all those tables that begin with a certain prefix string. In where condition just put the common prefix string in where condition (Like ‘prefix%’)
SELECT@query+=' DROP TABLE ' +QUOTENAME( +'.'+QUOTENAME(';' FROMsys.tablesASt INNERJOINsys.schemasASs ONt.[schema_id]=s.[schema_id] WHEREt.nameLIKE'MX_100%';
This query may create an issue, if a table has a foreign key relationship, you'll either need to drop them first or arrange the output to drop the tables in a certain order. If you want to monitor exactly what goes on when the query is running then use the following que…