Microsoft es bastante concreto en cuándo utilizar índices sobre campos XML y una de las situaciones donde no lo recomienda es cuando no se hacen muchas consultas sobre el campo XML. Vamos a ver esto.

Creamos una tabla temporal y añadimos sólo uno de los planes en caché grandes:

El tamaño de los datos son 18,4 MB y hemos tardado unos 9 s en cargar la tabla. Veamos qué pasa con el índice primario:

El tamaño del índice son 96,7 MB –es decir, cinco veces el tamaño de los datos– y se ha tardado en crear unos 20 s. Podemos apreciar el primer y principal problema de este tipo de índices: su tamaño.

Pero, ¿merece la pena? Para averiguarlo vamos a ejecutar la consulta optimada del artículo anterior con y sin los índices:

Pasamos de tardar 3 s –con índice– a 10 s –sin índice–, por lo que no compensa, porque se tarda la mitad en ejecutar la consulta que en crear el índice. Por esto nos dice Microsoft que creemos los índices cuando se consulten los campos XML repetidas veces. En nuestro caso en que queremos analizar documentos grandes, el crear el índice no ha supuesto una mejora. Sin embargo, si se consultase este documento en repetidas ocasiones, sí nos merecería la pena al tener un rendimiento 3x.

¿Nos ayudará alguno de los índices secundarios? La verdad es que no porque la consulta que estamos haciendo se resuelve perfectamente con el índice primario como podemos observar si examinamos el plan (muestro una parte nada más) donde todos los nodos iniciales se resuelven consultando el índice primario:

Es más, si creamos los índices secundarios para ver si los emplea y qué pasa:

Veremos en el plan que usa los índices primario y propiedad:

Cada índice secundario no es tan grande como el primario, en este caso son de 76,9 MB cada uno de los tres, pero en vez de acelerar la consulta, la hacen más lenta. Por lo tanto, como también nos dice Microsoft, tienen unos usos muy específicos.