Gua de diseo de ndices de SQL Server

Los ndices mal diseados y la falta de ndices constituyen las principales fuentes de atascos en
aplicaciones de base de datos. El diseo eficaz de los ndices tiene gran importancia para conseguir un
buen rendimiento de una base de datos y una aplicacin. Esta gua de diseo de ndices de SQL Server
contiene informacin y prcticas recomendadas que le ayudarn a disear ndices eficaces que
resuelvan las necesidades de la aplicacin.
En esta gua se da por supuesto que el lector tiene informacin general sobre los tipos de ndice
disponibles en SQL Server. Para obtener una descripcin general de los tipos de ndice, vea Tipos de
ndice.
En esta gua
Conceptos bsicos del diseo de ndices
Instrucciones generales de diseo de ndice
Directrices para disear ndices en clster
Directrices para disear ndices no clster
Directrices para disear ndices nicos
Directrices para disear ndices filtrados
Conceptos bsicos del diseo de ndices
Un ndice es una estructura de disco asociada con una tabla o una vista que acelera la recuperacin de
filas de la tabla o de la vista. Un ndice contiene claves generadas a partir de una o varias columnas de
la tabla o la vista. Dichas claves estn almacenadas en una estructura (rbol b) que permite que SQL
Server busque de forma rpida y eficiente la fila o filas asociadas a los valores de cada clave.
La seleccin de los ndices apropiados para una base de datos y su carga de trabajo es una compleja
operacin que busca el equilibrio entre la velocidad de la consulta y el costo de actualizacin. Los
ndices estrechos, o con pocas columnas en la clave de ndice, necesitan menos espacio en el disco y
son menos susceptibles de provocar sobrecargas debido a su mantenimiento. Por otra parte, la ventaja
de los ndices anchos es que cubren ms consultas. Puede que tenga que experimentar con distintos
diseos antes de encontrar el ndice ms eficaz. Es posible agregar, modificar y quitar ndices sin que
esto afecte al esquema de la base de datos o al diseo de la aplicacin. Por lo tanto, no debe dudar en
experimentar con ndices diferentes.
El optimizador de consultas de SQL Server elige de forma confiable el ndice ms eficaz en la mayora
de los casos. La estrategia general de diseo de ndices debe proporcionar una buena seleccin de
ndices al optimizador de consultas y confiar en que tomar la decisin correcta. As se reduce el
tiempo de anlisis y se obtiene un buen rendimiento en diversas situaciones. Para saber qu ndices
utiliza el optimizador de consultas para determinada consulta, en SQL Server Management Studio, en el
men Consulta , seleccione Incluir plan de ejecucin real.
No equipare siempre la utilizacin de ndices con un buen rendimiento ni el buen rendimiento al uso
eficaz del ndice. Si la utilizacin de un ndice contribuyera siempre a producir el mejor rendimiento, el
trabajo del optimizador de consultas sera muy sencillo. En realidad, una eleccin incorrecta de ndice
puede provocar un rendimiento bajo. Por tanto, la tarea del optimizador de consultas consiste en
seleccionar un ndice o una combinacin de ndices solo si mejora el rendimiento, y evitar la
recuperacin indizada cuando afecte al mismo.
Tareas del diseo de ndices
Las siguientes tareas componen la estrategia recomendada para el diseo de ndices:
1. Comprender las caractersticas de la propia base de datos. Por ejemplo, se trata de una base de
datos de procesamiento de transacciones en lnea (OLTP) con modificaciones frecuentes de
datos, o de una base de datos de sistema de ayuda a la toma de decisiones (DSS) o de
almacenamiento de datos (OLAP) que contiene principalmente datos de solo lectura y debe
procesar rpidamente conjuntos de datos muy grandes. En SQL Server 2012, el ndice
de almacn de columnas optimizado para memoria xVelocity resulta especialmente indicado
para los conjuntos de datos tpicos de almacenamiento de datos. Los ndices de almacn de
columnas pueden transformar la experiencia de almacenamiento de datos de los usuarios, ya
que permite un rendimiento ms rpido en las consultas habituales de almacenamiento de
datos, como el filtrado, la agregacin, la agrupacin y la combinacin en estrella de consultas.
Para obtener ms informacin, vea Columnstore Indexes Described.
1
 2. Comprender las caractersticas de las consultas utilizadas con frecuencia. Por ejemplo, saber
que una consulta utilizada con frecuencia une dos o ms tablas facilitar la determinacin del
mejor tipo de ndices que se puede utilizar.
3. Comprender las caractersticas de las columnas utilizadas en las consultas. Por ejemplo, un
ndice es idneo para columnas que tienen un tipo de datos entero y adems son columnas con
valores NULL o no NULL. En el caso de columnas que tengan subconjuntos de datos bien
definidos, puede usar un ndice filtrado en SQL Server 2008 y en versiones posteriores. Para
obtener ms informacin, vea Directrices generales para disear ndices filtrados en esta gua.
4. Determinar qu opciones de ndice podran mejorar el rendimiento al crear o mantener el ndice.
Por ejemplo, la creacin de un ndice clster en una tabla grande existente se beneficiara de la
opcin de ndice ONLINE. La opcin ONLINE permite que la actividad simultnea en los datos
subyacentes contine mientras el ndice se crea o regenera. Para obtener ms informacin,
consulte Establecer opciones de ndice.
5. Determinar la ubicacin de almacenamiento ptima para el ndice. Un ndice no clster se puede
almacenar en el mismo grupo de archivos que la tabla subyacente o en un grupo distinto. La
ubicacin de almacenamiento de ndices puede mejorar el rendimiento de las consultas
aumentando el rendimiento de las operaciones de E/S en disco. Por ejemplo, el almacenamiento
de un ndice no clster en un grupo de archivos que se encuentra en un disco distinto que el del
grupo de archivos de la tabla puede mejorar el rendimiento, ya que se pueden leer varios discos
al mismo tiempo.
O bien, los ndices clster y no clster pueden utilizar un esquema de particiones en varios
grupos de archivos. Las particiones facilitan la administracin de ndices y tablas grandes al
permitir el acceso y la administracin de subconjuntos de datos rpidamente y con eficacia,
mientras se mantiene la integridad de la coleccin global. Para obtener ms informacin,
vea Partitioned Tables and Indexes. Al considerar la posibilidad de utilizar particiones, determine
si el ndice debe alinearse; es decir, si las particiones se crean esencialmente del mismo modo
que la tabla o de forma independiente.
Instrucciones generales de diseo de ndice
Los administradores de bases de datos ms experimentados pueden disear un buen conjunto de
ndices, pero esta tarea es muy compleja, consume mucho tiempo y est sujeta a errores, incluso con
cargas de trabajo y bases de datos con un grado de complejidad no excesivo. La comprensin de las
caractersticas de la base de datos, las consultas y las columnas de datos facilita el diseo de los
ndices.
Consideraciones acerca de la base de datos
Cuando disee un ndice, tenga en cuenta las siguientes directrices acerca de la base de datos:
Si se usa un gran nmero de ndices en una tabla, el rendimiento de las instrucciones INSERT,
UPDATE, DELETE y MERGE se ver afectado, ya que todos los ndices deben ajustarse
adecuadamente a medida que cambian los datos de la tabla. Por ejemplo, si una columna se usa
en varios ndices y ejecuta una instruccin UPDATE que modifica datos de esa columna, se
deben actualizar todos los ndices que contengan esa columna, as como la columna de la tabla
base subyacente (ndice de montn o clster).
o Evite crear demasiados ndices en tablas que se actualizan con mucha frecuencia y
mantenga los ndices estrechos, es decir, defnalos con el menor nmero de columnas
posible.
o Utilice un nmero mayor de ndices para mejorar el rendimiento de consultas en tablas
con pocas necesidades de actualizacin, pero con grandes volmenes de datos. Un gran
nmero de ndices contribuye a mejorar el rendimiento de las consultas que no modifican
datos, como las instrucciones SELECT, ya que el optimizador de consultas dispone de
ms ndices entre los que elegir para determinar el mtodo de acceso ms rpido.
La indizacin de tablas pequeas puede no ser una solucin ptima, porque puede provocar que
el optimizador de consultas tarde ms tiempo en realizar la bsqueda de los datos a travs del
ndice que en realizar un simple recorrido de la tabla. De este modo, es posible que los ndices
de tablas pequeas no se utilicen nunca; sin embargo, sigue siendo necesario su mantenimiento
a medida que cambian los datos de la tabla.
Los ndices en vistas pueden mejorar de forma significativa el rendimiento si la vista contiene
agregaciones, combinaciones de tabla o una mezcla de agregaciones y combinaciones. No es
2
 necesario hacer referencia de forma explcita a la vista en la consulta para que el optimizador
de consultas la utilice.
Utilice el Asistente para la optimizacin de motor de base de datos para analizar las bases de
datos y crear recomendaciones de ndices. Para obtener ms informacin, vea Database Engine
Tuning Advisor.
Consideraciones sobre consultas
Cuando disee un ndice, tenga en cuenta las siguientes directrices acerca de las consultas:
Cree ndices no clster en las columnas que se usan con frecuencia en predicados y condiciones
de combinacin de las consultas. Sin embargo, debe evitar agregar columnas innecesarias. Si
agrega demasiadas columnas de ndice, puede reducir el espacio en disco y el rendimiento del
mantenimiento del ndice.
La utilizacin de ndices puede mejorar el rendimiento de las consultas, ya que los datos
necesarios para satisfacer las necesidades de la consulta existen en el propio ndice. Es decir,
solo se requieren las pginas de ndice, y no las pginas de datos de la tabla o el ndice clster,
para recuperar los datos solicitados; por lo tanto, se reduce la E/S de disco global. Por ejemplo,
una consulta de las columnas a y b en una tabla que tiene un ndice compuesto creado en las
columnas a, by c puede recuperar los datos especificados del ndice.
Escriba consultas que inserten o modifiquen tantas filas como sea posible en una sola
instruccin, en lugar de utilizar varias consultas para actualizar las mismas filas. Al utilizar solo
una instruccin, se puede aprovechar el mantenimiento de ndices optimizados.
Analice el tipo de la consulta y cmo se utilizan las columnas en ella. Por ejemplo, una columna
utilizada en una consulta de coincidencia exacta sera una buena candidata para un ndice no
clster o clster.
Consideraciones sobre columnas
Cuando disee un ndice, tenga en cuenta las siguientes directrices acerca de las columnas:
Utilice una longitud corta en la clave de los ndices clster. Los ndices clster tambin mejoran
si se crean en columnas nicas o que no admitan valores NULL.
Las columnas con tipos de
datos ntext, text, image, varchar(max), nvarchar(max)y varbinary(max) no se pueden
especificar como columnas de clave de ndice. Sin embargo, los tipos de
datos varchar(max), nvarchar(max), varbinary(max)y xml pueden participar en un ndice
no clster como columnas de ndice sin clave. Para obtener ms informacin, vea la
seccin 'ndice con columnas incluidas' en esta gua.
El tipo de datos xml solo puede ser una columna de clave en un ndice XML. Para obtener ms
informacin, consulte ndices XML (SQL Server). SQL Server 2012 SP1 presenta un nuevo tipo de
ndice XML denominado ndice XML selectivo. Este nuevo ndice puede mejorar el rendimiento
de las consultas en datos almacenados como XML en SQL Server, lo que permitir indizar mucho
ms rpidamente grandes cargas de trabajo de datos XML y mejorar la escalabilidad reduciendo
los costos de almacenamiento del propio ndice. Para obtener ms informacin, consulte ndices
XML selectivos (SXI).
Examine la unicidad de las columnas. Un ndice nico en lugar de un ndice no nico con la
misma combinacin de columnas proporciona informacin adicional al optimizador de consultas
y, por tanto, resulta ms til. Para obtener ms informacin, vea Directrices para disear ndices
nicos en esta gua.
Examine la distribucin de los datos en la columna. A menudo, se crean consultas cuya
ejecucin es muy larga al indizar una columna con pocos valores nicos, o bien al realizar una
combinacin en dicha columna. Se trata de un problema fundamental con los datos y la
consulta, y normalmente no se puede resolver sin identificar esta situacin. Por ejemplo, una
agenda telefnica ordenada por apellidos no localizar rpidamente a una persona si todas las
personas de la ciudad se llaman Smith o Jones. Para obtener ms informacin acerca de la
distribucin de datos, vea Statistics.
Considere la posibilidad de usar ndices filtrados en columnas que tengan subconjuntos bien
definidos, por ejemplo columnas dispersas, columnas con una mayora de valores NULL,
columnas con categoras de valores y columnas con intervalos de valores diferenciados. Un
ndice filtrado bien diseado puede mejorar el rendimiento de las consultas, as como reducir los
costos de almacenamiento y de mantenimiento de los ndices.
3
 Tenga en cuenta el orden de las columnas si el ndice va a contener varias columnas. La
columna que se usa en la clusula WHERE en una condicin de bsqueda igual a (=), mayor que
(>), menor que (<) o BETWEEN, o que participa en una combinacin, debe situarse en primer
lugar. Las dems columnas deben ordenarse basndose en su nivel de diferenciacin, es decir,
de ms distintas a menos distintas.
Por ejemplo, si el ndice se define como LastName, FirstName , resultar til si el criterio de
bsqueda es WHERE LastName = 'Smith' o WHERE LastName = Smith AND FirstName LIKE 'J%'. Sin
embargo, el optimizador de consultas no utilizar el ndice en una consulta que solo
busque FirstName (WHERE FirstName = 'Jane').
Tenga en cuenta la indizacin de columnas calculadas. Para obtener ms informacin,
vea Indexes on Computed Columns.
Caractersticas de los ndices
Despus de determinar que un ndice resulta adecuado para una consulta, puede seleccionar el tipo de
ndice que mejor se ajusta a la situacin. Entre las caractersticas de los ndices se incluyen:
ndices agrupados y no agrupados
ndices exclusivos y no exclusivos
ndices de una sola columna y de varias columnas
Orden ascendente o descendente en las columnas del ndice
ndices de tabla completa y filtrados en ndices no clster
Tambin puede personalizar las caractersticas iniciales de almacenamiento del ndice para optimizar
su rendimiento o mantenimiento; por ejemplo, puede establecer una opcin como FILLFACTOR.
Adems, puede determinar la ubicacin de almacenamiento del ndice si utiliza grupos de archivos o
esquemas de particin y mejorar as el rendimiento.
Colocacin de ndices en grupos de archivos o esquemas de particiones
Al desarrollar la estrategia de diseo del ndice, debe tener en cuenta la ubicacin de los ndices en los
grupos de archivos asociados con la base de datos. La seleccin cuidadosa del grupo de archivos o del
esquema de particin puede mejorar el rendimiento de la consulta.
De forma predeterminada, los ndices se almacenan en el mismo grupo de archivos que la tabla base
en la que se crea el ndice. Un ndice clster sin particiones y la tabla base siempre residen en el mismo
grupo de archivos. Sin embargo, puede hacer lo siguiente:
Crear ndices no clster en un grupo de archivos diferente del grupo de archivos de la tabla base
o el ndice clster.
Crear particiones de ndices clster y no clster repartidos en varios grupos de archivos.
Mover una tabla de un grupo de archivos a otro quitando el ndice clster y especificando un
nuevo grupo de archivos o un esquema de particin en la clusula MOVE TO de la instruccin
DROP INDEX o utilizando la instruccin CREATE INDEX con la clusula DROP_EXISTING.
Si se crea el ndice no clster en otro grupo de archivos, es posible mejorar el rendimiento si los grupos
de archivos utilizan distintas unidades fsicas con sus propios controladores. De ese modo, la
informacin de ndice y los datos pueden leerse en paralelo mediante varios cabezales de disco. Por
ejemplo, si la misma consulta emplea Table_A del grupo de archivos f1 e Index_A del grupo de
archivos f2 , se puede mejorar el rendimiento porque ambos grupos de archivos se estn usando sin
contencin. Sin embargo, si la consulta examina Table_A pero no se hace referencia a Index_A , solo se
usar el grupo de archivos f1 . Esto no produce ninguna mejora de rendimiento.
Como no se puede predecir qu tipo de acceso tendr lugar ni cundo, la mejor decisin consiste en
repartir las tablas e ndices en todos los grupos de archivos. De este modo se garantiza el acceso a
todos los discos, ya que todos los datos e ndices estn repartidos por igual entre todos los discos
independientemente de la forma de acceso a los datos. Tambin se trata de un mtodo ms sencillo
para los administradores de sistemas.
Particiones entre varios grupos de archivos
Tambin puede considerar la opcin de crear particiones de clster y no clster en varios grupos de
archivos. Los ndices con particiones se dividen horizontalmente o por filas, basndose en una funcin
de particin. La funcin de particin define cmo se asigna cada fila a un conjunto de particiones en los
valores de ciertas columnas, denominadas columnas de particin. Un esquema de particin especifica
la asignacin de las particiones a un conjunto de grupos de archivos.
La creacin de particiones de un ndice puede proporcionar las siguientes ventajas:

4
 Proporcionar sistemas escalables que hacen que los ndices grandes sean ms fciles de
administrar. Los sistemas OLTP, por ejemplo, pueden implementar aplicaciones orientadas a
particiones que gestionan ndices grandes.
Realizar consultas de forma ms rpida y eficiente. Cuando las consultas tienen acceso a varias
particiones de un ndice, el optimizador de consultas puede procesar particiones individuales
simultneamente y excluir particiones que no estn afectadas por la consulta.
Para obtener ms informacin, consulte Partitioned Tables and Indexes.
Directrices para diseo de criterio de ordenacin de ndices
Al definir ndices, debe tenerse en cuenta si los datos de la columna de clave de ndice se almacenan
en orden ascendente o descendente. El orden ascendente es el predeterminado y mantiene la
compatibilidad con las versiones anteriores de SQL Server. La sintaxis de las instrucciones CREATE
INDEX, CREATE TABLE y ALTER TABLE admite las palabras clave ASC (ascendente) y DESC
(descendente) en columnas individuales de ndices y restricciones.
La especificacin del orden en que se almacenan los valores de clave en un ndice es de utilidad
cuando las consultas que hacen referencia a la tabla tienen clusulas ORDER BY que especifican
distintas direcciones para las columnas de clave del ndice. En estos casos, el ndice puede eliminar la
necesidad de un operador SORT en el plan de consultas, lo que aumenta la eficacia de la consulta. Por
ejemplo, los compradores del departamento de compras de Adventure Works Cycles tienen que evaluar
la calidad de los productos que compran a los proveedores. Los compradores estn especialmente
interesados en buscar productos enviados por estos proveedores con una tasa alta de rechazos. Como
se muestra en la siguiente consulta, para recuperar los datos que cumplen estos criterios es necesario
organizar la columna RejectedQty de la tabla Purchasing.PurchaseOrderDetail en orden descendente (de
mayor a menor) y la columna ProductID en orden ascendente (de menor a mayor).
SELECT RejectedQty, ((RejectedQty/OrderQty)*100) AS RejectionRate,
ProductID, DueDate
FROM Purchasing.PurchaseOrderDetail
ORDER BY RejectedQty DESC, ProductID ASC;
El siguiente plan de ejecucin para esta consulta muestra que el optimizador de consultas utiliz un
operador SORT para devolver el conjunto de resultados en el orden especificado mediante la clusula
ORDER BY.

Si se crea un ndice con columnas de clave que coincidan con las de la clusula ORDER BY de la
consulta, se puede eliminar el operador SORT del plan de consultas y ste resulta ms eficaz.
CREATE NONCLUSTERED INDEX IX_PurchaseOrderDetail_RejectedQty
ON Purchasing.PurchaseOrderDetail
(RejectedQty DESC, ProductID ASC, DueDate, OrderQty);
Cuando se ejecuta de nuevo la consulta, el plan de consultas siguiente muestra que se ha eliminado el
operador SORT y se utiliza el ndice no clster que se acaba de crear.

Motor de base de datos puede moverse con la misma eficacia en cualquier direccin. Un ndice definido
como (RejectedQty DESC, ProductID ASC) se puede seguir utilizando para una consulta en la que se
invierte la direccin de ordenacin de las columnas en la clusula ORDER BY. Por ejemplo, una consulta
con la clusula ORDER BY ORDER BY RejectedQty ASC, ProductID DESC puede utilizar el ndice.
Solo se pueden especificar criterios de ordenacin para columnas de clave. La vista de
catlogo sys.index_columns y la funcin INDEXKEY_PROPERTY informan de si una columna de ndice
est almacenada en orden ascendente o descendente.
Directrices para disear ndices en clster
5
Los ndices clster ordenan y almacenan las filas de los datos de la tabla de acuerdo con los valores de
la clave del ndice. Solo puede haber un ndice clster por cada tabla, porque las filas de datos solo
pueden estar ordenadas de una forma. Salvo excepciones, todas las tablas deben incluir un ndice
clster definido en las columnas que presenten las siguientes caractersticas:
Se pueden utilizar en consultas frecuentes.
Proporcionan un alto grado de unicidad.
Se pueden utilizar en consultas por rango.
Nota:
Cuando crea una restriccin PRIMARY KEY, se crea automticamente un ndice nico en las columnas. De
forma predeterminada, este ndice es clster; sin embargo, puede especificar un ndice no clster cuando
crea la restriccin.
Si el ndice clster no se crea con la propiedad UNIQUE, el Motor de base de datos agrega
automticamente una columna de valor de unicidad de 4 bytes a la tabla. Cuando es necesario, el
Motor de base de datos agrega automticamente un valor de unicidad a una fila para hacer que cada
clave sea nica. Esta columna y sus valores se utilizan de forma interna; los usuarios no pueden verlos
ni tener acceso a ellos.
Arquitectura de los ndices clster
En SQL Server, los ndices se organizan como rboles b. Las pginas de un rbol b de ndice se llaman
nodos del ndice. El nodo superior del rbol b se llama nodo raz. Los nodos inferiores del ndice se
denominan nodos hoja. Los niveles del ndice entre el nodo raz y los nodos hoja se conocen en
conjunto como niveles intermedios. En un ndice clster, los nodos hoja contienen las pginas de datos
de la tabla subyacente. El nodo raz y los nodos intermedios incluyen pginas de ndice que contienen
filas de ndice. Cada fila de ndice contiene un valor clave y un puntero a una pgina de nivel
intermedio en el rbol b, o bien a una fila de datos del nivel hoja del ndice. Las pginas de cada nivel
del ndice se vinculan en una lista con vnculos dobles.
Los ndices clster tienen una fila en sys.partitions, con index_id = 1 para cada particin utilizada por
el ndice. De forma predeterminada, un ndice clster tiene una sola particin. Cuando un ndice clster
tiene mltiples particiones, cada particin tiene una estructura de rbol b que contiene los datos de esa
particin especfica. Por ejemplo, si un ndice clster tiene cuatro particiones, hay cuatro estructuras de
rbol b, una en cada particin.
En funcin de los tipos de datos del ndice clster, cada estructura de ndice clster tendr una o ms
unidades de asignacin en las que almacenar y administrar los datos de una particin especfica. Como
mnimo, cada ndice clster tendr una unidad de asignacin IN_ROW_DATA por particin. El ndice
clster tambin tendr una unidad de asignacin LOB_DATA por particin si contiene columnas de
objetos grandes (LOB). Tambin tendr una unidad de asignacin ROW_OVERFLOW_DATA por particin
si contiene columnas de longitud variable que superen el lmite de tamao de fila de 8.060 bytes.
Las pginas de la cadena de datos y las filas que contienen se ordenan segn el valor de la clave de
ndice clster. Todas las inserciones se hacen en el punto en el que el valor de clave de la fila insertada
quede dentro de la secuencia de orden entre las filas existentes.
En esta ilustracin se muestra la estructura de un ndice clster en una sola particin.

6
Consideraciones sobre consultas
Antes de crear ndices clster, debe conocer cmo se tiene acceso a los datos. Considere que utiliza un
ndice clster en consultas que realizan lo siguiente:
Devuelven un intervalo de valores mediante la utilizacin de operadores como BETWEEN, >,
>=, < y <=.
Cuando la fila se encuentra con el primer valor mediante el ndice clster, se garantiza que las
filas con los valores indizados posteriores son fsicamente adyacentes. Por ejemplo, si una
consulta recupera registros entre un intervalo de nmeros de pedidos de ventas, un ndice
clster en la columna SalesOrderNumber puede encontrar rpidamente la fila que contiene el
nmero de pedido de ventas inicial y, a continuacin, recuperar todas las filas sucesivas de la
tabla hasta llegar al ltimo nmero de pedido de ventas.
Devuelven grandes conjuntos de resultados.
Utilizan clusulas JOIN; por lo general, son columnas de clave externa.
Utilizan clusulas ORDER BY o GROUP BY.
Un ndice en las columnas especificadas en la clusula ORDER BY o GROUP BY puede eliminar la
necesidad de que Motor de base de datos ordene los datos, puesto que las filas ya estn
ordenadas. De ese modo, el rendimiento de las consultas aumenta.
Consideraciones sobre columnas
Por regla genera, debe definir la clave de ndice clster con el menor nmero de columnas posible.
Considere columnas que cuentan con uno o varios de los siguientes atributos:
Son nicas o contienen muchos valores distintos
Por ejemplo, un Id. de empleado identifica de forma exclusiva a los empleados. Un ndice clster
o una restriccin PRIMARY KEY en la columna EmployeeID mejorara el rendimiento de las
consultas que buscan informacin de empleado segn el nmero de identificador del empleado.
Tambin se podra crear un ndice clster en las columnas LastName, FirstNamey MiddleName , ya
que los registros de empleados se suelen agrupar y consultar de esta forma, y la combinacin
de estas columnas seguira proporcionando un alto grado de diferencia.
Se tiene acceso a ellas de forma secuencial
Por ejemplo, un identificador de producto identifica de forma exclusiva los productos de la
tabla Production.Product en la base de datos AdventureWorks2012 . Un ndice clster
en WHERE ProductID BETWEEN 980 and 999mejorara las consultas en las que se especifica una

7
 bsqueda secuencial, como ProductID. Esto se debe a que las filas se almacenan de forma
ordenada en esta columna de clave.
Se define como IDENTITY.
Se utilizan con frecuencia para ordenar los datos recuperados de una tabla
Puede resultar conveniente agrupar, es decir, ordenar fsicamente la tabla de dicha columna
para evitar una operacin de ordenacin cada vez que se consulta la columna.
Los ndices clster no son adecuados para los siguientes atributos:
Columnas sometidas a cambios frecuentes
Esto provoca que se mueva toda la fila, ya que Motor de base de datos debe mantener los
valores de los datos de la fila ordenados fsicamente. Esta consideracin es importante en
sistemas de procesamiento de transacciones de gran volumen en los que los datos tienden a ser
voltiles.
Claves amplias
Las claves amplias se componen de varias columnas o varias columnas de gran tamao. Los
valores clave del ndice clster se utilizan en todos los ndices no clster como claves de
bsqueda. Los ndices no clster definidos en la misma tabla sern bastante ms grandes, ya
que sus entradas contienen la clave de agrupacin en clsteres y las columnas de clave
definidas para dicho ndice no clster.
Directrices para disear ndices no clster
Un ndice no clster contiene los valores de clave del ndice y localizadores de fila que apuntan a la
ubicacin de almacenamiento de los datos de tabla. Se pueden crear varios ndices no clster en una
tabla o una vista indizada. Por lo general, se deben disear ndices no clster para mejorar el
rendimiento de consultas utilizadas con frecuencia no cubiertas por el ndice clster.
Al igual que cuando se utiliza un ndice de un libro, el optimizador de consultas busca valores de datos
en el ndice no clster para encontrar la ubicacin del valor de datos en la tabla y, a continuacin,
recupera los datos directamente de esa ubicacin. Este sistema convierte a los ndices no clster en la
opcin ms apropiada para las consultas de coincidencia exacta, dado que el ndice contiene entradas
que describen la ubicacin exacta en la tabla de los valores de datos que se buscan en las consultas.
Por ejemplo, para consultar la tabla HumanResources. Employee con el fin de ver todos los subordinados
de un jefe determinado, el optimizador de consultas podra usar el ndice no
clster IX_Employee_ManagerID, que tiene ManagerID como columna de clave. El optimizador de consultas
puede buscar rpidamente todas las entradas del ndice que coinciden con el ManagerIDespecificado.
Cada entrada de ndice apunta a la pgina y fila exactas de la tabla, o ndice clster, en que se pueden
encontrar los datos correspondientes. Una vez que el optimizador de consultas busca todas las
entradas del ndice, puede ir directamente a la pgina y fila exactas para recuperar los datos.
Arquitectura de los ndices no clster
Los ndices no clster tienen la misma estructura de rbol b que los ndices clster, excepto por las
siguientes diferencias importantes:
Las filas de datos de la tabla subyacente no estn ordenadas ni almacenadas basndose en sus
claves no agrupadas.
La capa de hoja de un ndice no clster est compuesta por pginas de ndices, en lugar de
pginas de datos.
Los localizadores de filas de las filas de ndices no clster pueden ser un puntero a la fila o una clave de
ndice clster para una fila, tal como se describe a continuacin:
Si la tabla es un montn, lo que significa que no tiene ningn ndice clster, el localizador de fila
es un puntero a la fila. El puntero se genera a partir del identificador (Id.) de archivo, el nmero
de pgina y el nmero de la fila dentro de la pgina. El puntero completo se conoce como Id. de
fila (RID).
Si la tabla tiene un ndice clster o si el ndice est en una vista indizada, el localizador de fila es
la clave del ndice clster para la fila.
Los ndices no agrupados tienen una fila en sys.partitions, con index_id >1 para cada particin usada
por el ndice. De forma predeterminada, un ndice no clster tiene una sola particin. Cuando un ndice
no clster tiene varias particiones, cada una tiene una estructura de rbol b que contiene las filas de
ndice de esa particin especfica. Por ejemplo, si un ndice no clster tiene cuatro particiones, habr
cuatro estructuras de rbol b, una en cada particin.

8
En funcin de los tipos de datos del ndice no clster, cada estructura de ndice no clster tendr una o
ms unidades de asignacin en las que almacenar y administrar los datos de una particin especfica.
Como mnimo, cada ndice no clster tendr una unidad de asignacin IN_ROW_DATA por particin
encargada de almacenar las pginas de rbol b del ndice. El ndice no clster tambin tendr una
unidad de asignacin LOB_DATA por particin si contiene columnas de objetos grandes (LOB). Tambin
tendr una unidad de asignacin ROW_OVERFLOW_DATA por particin si contiene columnas de longitud
variable que superen el lmite de tamao de fila de 8.060 bytes.
En la siguiente ilustracin se muestra la estructura de un ndice no clster en una sola particin.

Consideraciones acerca de la base de datos

Tenga en cuenta las caractersticas de la base de datos al disear ndices no clster.
Las bases de datos o tablas que exigen pocos requisitos para la actualizacin, pero suelen
contener un gran volumen de datos, se pueden beneficiar de muchos ndices no clster para
mejorar el optimizador de consultas. Considere la creacin de ndices filtrados para
subconjuntos bien definidos de datos con el fin de mejorar el rendimiento de las consultas,
reducir los costos de almacenamiento del ndice y reducir los costos de mantenimiento del
ndice en comparacin con ndices no clster de la tabla completa.
Las aplicaciones y bases de datos del sistema de ayuda para la toma de decisiones que
contienen principalmente datos de solo lectura se pueden beneficiar de muchos ndices no
clster. El optimizador de consultas tiene ms ndices entre los que elegir para determinar el
mtodo de acceso ms rpido. Adems, las caractersticas que exigen pocos requisitos para la
actualizacin de la base de datos se traducen en que el mantenimiento de los ndices no
reducir el rendimiento.
Las aplicaciones y bases de datos de procesamiento de transacciones en lnea (OLTP) que
contienen tablas deben evitar el exceso de ndices. Adems, los ndices deben ser estrechos, es
decir, con la menor cantidad de columnas posible.
Si se utiliza un gran nmero de ndices en una tabla, el rendimiento de las instrucciones INSERT,
UPDATE, DELETE y MERGE se ver afectado, ya que todos los ndices deben ajustarse
adecuadamente a medida que cambian los datos de la tabla.
Consideraciones sobre consultas
Antes de crear ndices no clster, debe conocer cmo se tiene acceso a los datos. Considere la
posibilidad de utilizar un ndice no clster para consultas que cuentan con los siguientes atributos:
Utilizan clusulas JOIN o GROUP BY.
Crean varios ndices no clster para las columnas que intervienen en operaciones de
combinacin y de agrupacin, y un ndice clster para las columnas de clave externa.
9
 No devuelven conjuntos de resultados de gran tamao.
Cree ndices filtrados para atender consultas que devuelven un subconjunto bien definido de
filas en una tabla grande.
Contienen columnas que suelen incluirse en las condiciones de bsqueda de una consulta, como
la clusula WHERE, que devuelven coincidencias exactas.
Consideraciones sobre columnas
Tenga en cuenta las columnas que tengan uno o varios de estos atributos:
Cubren la consulta.
Se obtienen mejoras de rendimiento cuando el ndice contiene todas las columnas de la
consulta. El optimizador de consultas puede buscar todos los valores de columna del ndice; no
se tiene acceso a los datos de tabla o de ndice clster, lo que se traduce en menos operaciones
de E/S de disco. Utilice un ndice con columnas incluidas para agregar columnas de cobertura en
lugar de crear una clave de ndice ancho.
Si la tabla tiene un ndice clster, las columnas definidas en l se anexan automticamente al
final de cada ndice no clster de la tabla. Esto puede producir una consulta cubierta sin
especificar las columnas de ndice clster en la definicin del ndice no clster. Por ejemplo, si
una tabla tiene un ndice clster en la columna C, un ndice no clster en las
columnas B y A tendr como columnas de valores de clave las columnas B, Ay C.
Gran nmero de valores distintos, como combinaciones de nombres y apellidos, si se utiliza un
ndice clster para otras columnas.
Si hay muy pocos valores distintos, como solo 1 y 0, la mayora de las consultas no utilizarn el
ndice, ya que una exploracin de la tabla suele ser ms eficaz. Para este tipo de datos,
considere la creacin de un ndice filtrado en un valor distintivo que solo se da en un nmero
pequeo de filas. Por ejemplo, si la mayora de los valores es 0, el optimizador de consultas
puede utilizar un ndice filtrado para las filas de datos que contienen 1.
Usar columnas incluidas para ampliar ndices no clster
Puede ampliar la funcionalidad de ndices no clster agregando columnas sin clave en el nivel hoja del
ndice no clster. Al incluir columnas sin clave, puede crear ndices no clster que abarcan ms
consultas. Esto se debe a que las columnas sin clave tienen las siguientes ventajas:
Pueden ser tipos de datos que no estn permitidos como columnas de clave de ndice.
El Motor de base de datos no las tiene en cuenta cuando calcula el nmero de columnas de
clave de ndice o el tamao de clave de ndice.
Un ndice con columnas sin clave incluidas puede mejorar significativamente el rendimiento de una
consulta cuando todas las columnas de la consulta se incluyen como columnas de clave o columnas sin
clave. Las mejoras en el rendimiento se consiguen porque el optimizador de consultas puede localizar
todos los valores de las columnas del ndice, sin tener acceso a los datos de la tabla o del ndice
clster, lo que da como resultado menos operaciones de E/S de disco.

Nota

Cuando un ndice contiene todas las columnas a las que hace referencia la consulta, normalmente se dice
que abarca la consulta.
Las columnas de clave se almacenan en todos los niveles del ndice, mientras que las columnas sin
clave solo se almacenan en el nivel hoja.
Usar columnas incluidas para evitar lmites de tamao
Puede incluir columnas sin clave en un ndice no clster para evitar que supere las limitaciones
actuales de tamao del ndice de un mximo de 16 columnas de clave y un tamao mximo de las
claves de ndice de 900 bytes. El Motor de base de datos no tiene en cuenta las columnas sin clave al
calcular el nmero de columnas de clave de ndice o el tamao de clave de ndice.
Por ejemplo, suponga que desea indizar las siguientes columnas de la tabla Document :
Title nvarchar(50)
Revision nchar(5)
FileName nvarchar(400)
Puesto que los tipos de datos nchar y nvarchar necesitan 2 bytes para cada carcter, un ndice que
contenga estas tres columnas superara la limitacin de tamao de 900 bytes en 10 bytes (455 * 2). Al
utilizar la clusula INCLUDE de la instruccin CREATE INDEX, la clave de ndice se puede definir como
10
(Title, Revision) y FileName como columna sin clave. De esta forma, el tamao de las claves de ndice
sera de 110 bytes (55 * 2) y el ndice seguira conteniendo todas las columnas necesarias. La siguiente
instruccin crea ese ndice.
CREATE INDEX IX_Document_Title
ON Production.Document (Title, Revision)
INCLUDE (FileName);
Directrices del ndice con columnas incluidas
Cuando disee ndices no clster con columnas incluidas tenga en cuenta las siguientes directrices:
Las columnas sin clave se definen en la clusula INCLUDE de la instruccin CREATE INDEX.
Las columnas sin clave solo se pueden definir en ndices no clster en tablas o vistas indizadas.
Se admiten todos los tipos de datos, a excepcin de text, ntexte image.
Las columnas calculadas que son deterministas, y precisas o imprecisas, pueden ser columnas
incluidas. Para obtener ms informacin, vea Indexes on Computed Columns.
Al igual que con las columnas de clave, las columnas calculadas derivadas de los tipos de
datos image, ntexty text pueden ser columnas sin clave (incluidas) siempre que se permita el
tipo de datos de la columna calculada como columna de ndice sin clave.
Los nombres de columna no se pueden especificar en la lista INCLUDE y en la lista de columnas
de clave.
Los nombres de columna no se pueden repetir en la lista INCLUDE.
Directrices del tamao de columnas
Es necesario definir como mnimo una columna de clave. El nmero mximo de columnas sin
clave es de 1023 columnas. ste es el nmero mximo de columnas de la tabla menos 1.
Las columnas de clave de ndice, excluyendo las sin clave, deben seguir las restricciones de
tamao de ndice existentes de 16 columnas de clave como mximo y un tamao de las claves
de ndice total de 900 bytes.
El tamao total de todas las columnas sin clave solo est limitado por el tamao de las
columnas especificadas en la clusula INCLUDE; por ejemplo, las
columnas varchar(max) estn limitadas a 2 GB.
Directrices para modificar columnas
Cuando se modifica una columna de tabla que se ha definido como una columna incluida, se aplican las
siguientes restricciones:
Las columnas sin clave no se pueden quitar de la tabla, a menos que antes se quite el ndice.
Las columnas sin clave no se pueden cambiar, excepto para hacer lo siguiente:
o Cambiar la nulabilidad de NOT NULL a NULL.
o Aumentar la longitud de las columnas varchar, nvarcharo varbinary .

Nota

Tambin se aplican restricciones de modificacin a las columnas de clave de ndice.

Recomendaciones de diseo
Redisee ndices no clster con un tamao de las claves de ndice grande para que solo las columnas
utilizadas para bsquedas sean columnas de clave. Haga que todas las dems columnas que abarcan la
consulta sean columnas sin clave incluidas. De esta forma, tendr todas las columnas necesarias para
abarcar la consulta pero la clave de ndice en s ser pequea y eficaz.
Por ejemplo, suponga que desea disear un ndice para abarcar la siguiente consulta.
SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode
FROM Person.Address
WHERE PostalCode BETWEEN N'98000' and N'99999';
Para abarcar la consulta, cada columna debe definirse en el ndice. Aunque puede definir todas las
columnas como columnas de clave, el tamao de clave debe ser de 334 bytes. Como la nica columna
que se usa de verdad como criterio de bsqueda es la columna PostalCode , que tiene una longitud de
30 bytes, un mejor diseo del ndice definira PostalCode como columna de clave e incluira todas las
dems columnas como columnas sin clave.
La siguiente instruccin crea un ndice con columnas incluidas para abarcar la consulta.
CREATE INDEX IX_Address_PostalCode

11
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
Consideraciones de rendimiento
Evite agregar columnas que no sean necesarias. El hecho de agregar demasiadas columnas de ndice,
con o sin clave, puede tener las siguientes consecuencias en el rendimiento:
Cabrn menos filas de ndice en una pgina. Esto puede crear incrementos de E/S y una
reduccin de la eficacia de la cach.
Se necesitar ms espacio en disco para almacenar el ndice. En concreto, al agregar los tipos
de datos varchar(max), nvarchar(max), varbinary(max)o xml como columnas de ndice sin
clave, se pueden aumentar significativamente los requisitos de espacio en disco. Esto se debe a
que los valores de columnas se copian en el nivel hoja del ndice. Por lo tanto, residen en el
ndice y en la tabla base.
Puede que el mantenimiento del ndice haga aumentar el tiempo necesario para realizar
operaciones de modificacin, insercin, actualizacin o eliminacin en la tabla subyacente o la
vista indizada.
Debe determinar si la mejora del rendimiento de las consultas compensa el efecto en el rendimiento
durante la modificacin de datos y en los requisitos de espacio en disco adicionales.
Directrices para disear ndices nicos
Un ndice nico garantiza que la clave de ndice no contiene valores duplicados y, por tanto, cada fila
de la tabla es en cierta forma nica. Resulta conveniente especificar un ndice nico solo si los propios
datos se caracterizan por ser nicos. Por ejemplo, para asegurarse de que los valores de la
columna NationalIDNumber de la tabla HumanResources.Employee son nicos, cuando la clave principal
es EmployeeID, cree una restriccin UNIQUE en la columna NationalIDNumber . Si el usuario intenta
especificar el mismo valor en esa columna para ms de un empleado, se mostrar un mensaje de error
que impedir la entrada del valor duplicado.
En el caso de ndices nicos para varias columnas, el ndice asegura que cada combinacin de valores
de la clave de ndice sea nica. Por ejemplo, si se crea un ndice nico en una combinacin de
columnas LastName, FirstNamey MiddleName , dos filas de la tabla no podrn tener la misma combinacin
de valores para estas columnas.
Tanto los ndices clster como los no clster pueden ser nicos. Siempre que los datos de la columna
sean nicos, puede crear para la misma tabla un ndice clster nico y varios ndices clster no nicos.
Entre las ventajas de utilizar ndices nicos se incluyen:
Se garantiza la integridad de los datos de las columnas definidas.
Se proporciona informacin adicional til para el optimizador de consultas.
Si se crea una restriccin PRIMARY KEY o UNIQUE, se crear automticamente un ndice nico en las
columnas especificadas. No existen diferencias significativas entre la creacin de una restriccin
UNIQUE y la creacin de un ndice nico independiente de una restriccin. La validacin de los datos
tiene lugar de la misma manera y el optimizador de consultas no establece diferencias entre un ndice
nico creado por una restriccin y uno creado manualmente. Sin embargo, deber crear una restriccin
UNIQUE o PRIMARY KEY en la columna cuando el objetivo sea la integridad de los datos. Al hacer esto,
el objetivo del ndice quedar claro.
Consideraciones
Un ndice nico, una restriccin UNIQUE o una restriccin PRIMARY KEY no se pueden crear si
existen valores de clave duplicados en los datos.
Si los datos son nicos y desea hacer cumplir la exclusividad, la creacin de un ndice nico en
lugar de un ndice no nico en la misma combinacin de columnas proporciona informacin
adicional para el optimizador de consultas que puede dar como resultado unos planes de
ejecucin ms eficaces. En este caso se recomienda crear un ndice nico (preferiblemente
mediante una restriccin UNIQUE).
Un ndice no clster nico puede incluir columnas sin clave. Para obtener ms informacin,
vea ndice con columnas incluidas.
Directrices para disear ndices filtrados
Un ndice filtrado es un ndice no clster optimizado, especialmente indicado para atender consultas
que realizan selecciones a partir un subconjunto bien definido de datos. Utiliza un predicado de filtro
para indizar una parte de las filas de la tabla. Un ndice filtrado bien diseado puede mejorar el
12
rendimiento de las consultas y reducir los costos de almacenamiento del ndice en relacin con los
ndices de tabla completa, as como los costos de mantenimiento.

Se aplica a: desde SQL Server 2008 hasta SQL Server 2014.

Los ndices filtrados pueden proporcionar las siguientes ventajas respecto a los ndices de tabla
completa:
Calidad del rendimiento y el plan de consulta mejorada
Un ndice filtrado bien diseado mejora el rendimiento de las consultas y la calidad del plan de
ejecucin porque es menor que un ndice no clster de tabla completa y tiene estadsticas
filtradas. Las estadsticas filtradas son ms precisas que las de tabla completa porque
corresponden solamente a las filas del ndice filtrado.
Costos de mantenimiento de ndices reducidos
El mantenimiento de un ndice se realiza nicamente cuando las instrucciones de lenguaje de
manipulacin de datos (DML) afectan a los datos en el ndice. Un ndice filtrado reduce los
costos de mantenimiento del ndice en comparacin con un ndice no clster de tabla completa,
ya que es menor y el mantenimiento se realiza nicamente cuando se ven afectados los datos
del ndice. Se puede disponer de una gran cantidad de ndices filtrados, sobre todo cuando
contienen datos que raramente se ven afectados. De igual forma, si un ndice filtrado contiene
nicamente datos que se ven afectados a menudo, el tamao menor del ndice reduce el costo
de actualizacin de las estadsticas.
Costos de almacenamiento de ndices reducidos
La creacin de un ndice filtrado puede reducir la cantidad de almacenamiento en disco de
ndices no clster, cuando no sea necesario un ndice de tabla completa. Puede reemplazar un
ndice no clster de tabla completa con varios ndices filtrados sin aumentar de forma
considerable los requisitos de almacenamiento.
Los ndices filtrados son tiles cuando las columnas contienen subconjuntos de datos bien definidos a
los que las consultas hacen referencia en instrucciones SELECT. Algunos ejemplos son:
Columnas dispersas que contienen solamente unos pocos valores distintos de NULL.
Columnas heterogneas que contienen categoras de datos.
Columnas que contienen intervalos de valores como cantidad de dinero, hora y fechas.
Particiones de tablas definidas por lgica de comparacin simple para los valores de las
columnas.
La reduccin de los costos de mantenimiento para los ndices filtrados es ms apreciable cuando el
nmero de filas del ndice es pequeo en relacin con un ndice de tabla completa. Si el ndice filtrado
incluye la mayora de las filas en la tabla, puede resultar ms costoso mantenerlo que un ndice de
tabla completa. En ese caso, debe utilizar un ndice de tabla completa en lugar de un ndice filtrado.
Los ndices filtrados se definen en una tabla y solamente admiten operadores de comparacin simples.
Cuando necesite una expresin de filtro que haga referencia a varias tablas o que tenga lgica
compleja, deber crear una vista.
Consideraciones de diseo
Para disear ndices filtrados efectivos, es importante entender qu consultas utiliza la aplicacin y
cmo se relacionan con los subconjuntos de datos. Algunos ejemplos de datos que tienen subconjuntos
bien definidos son las columnas con una mayora de valores NULL, las columnas con categoras de
valores heterogneas y las columnas con intervalos de valores diferenciados. Las siguientes
consideraciones del diseo proporcionan una variedad de escenarios en los que un ndice filtrado puede
ofrecer ventajas sobre los ndices de tabla completa.
ndices filtrados para subconjuntos de datos
Cuando una columna solamente tiene un nmero pequeo de valores pertinentes para las consultas,
puede crear un ndice filtrado en el subconjunto de valores. Por ejemplo, cuando los valores en una
columna son principalmente NULL y la consulta solamente selecciona entre valores distintos de NULL,
puede crear un ndice filtrado para las filas de datos distintos de NULL. El ndice resultante ser menor
y tendr costos de mantenimiento ms reducidos que los de un ndice no clster de tabla completa
definido en las mismas columnas de clave.

13
Por ejemplo, la base de datos AdventureWorks2012 tiene una tabla Production.BillOfMaterials con 2679
filas. La columna EndDate solo tiene 199 filas que contienen un valor distinto de NULL y las otras 2.480
filas contienen valores NULL. El siguiente ndice filtrado atender consultas que devuelven las
columnas definidas en el ndice y que seleccionan nicamente filas con un valor distinto de NULL
para EndDate.
CREATE NONCLUSTERED INDEX FIBillOfMaterialsWithEndDate
ON Production.BillOfMaterials (ComponentID, StartDate)
WHERE EndDate IS NOT NULL ;
GO
El ndice filtrado FIBillOfMaterialsWithEndDate es vlido para la consulta siguiente. Puede mostrar el plan
de ejecucin de consultas para determinar si el optimizador de consultas ha utilizado el ndice filtrado.
SELECT ProductAssemblyID, ComponentID, StartDate
FROM Production.BillOfMaterials
WHERE EndDate IS NOT NULL
AND ComponentID = 5
AND StartDate > '20080101' ;
Para obtener ms informacin sobre cmo crear ndices filtrados y cmo definir la expresin de
predicado del ndice filtrado, vea Create Filtered Indexes.
ndices filtrados para datos heterogneos
Cuando una tabla tiene filas de datos heterogneos, se puede crear un ndice filtrado para una o varias
categoras de datos.
Por ejemplo, cada uno de los productos de la tabla Production.Product est asignado a
un ProductSubcategoryIDque, a su vez, est asociado a las categoras de producto Bikes, Components,
Clothing o Accessories. Estas categoras son heterogneas porque sus valores de columna en la
tabla Production.Product no estn suficientemente correlacionados. Por ejemplo, las
columnas Color, ReorderPoint, ListPrice, Weight, Classy Style tienen caractersticas nicas para cada
categora de producto. Suponga que se realizan consultas frecuentes de accesorios cuyas
subcategoras estn comprendidas entre 27 y 36 inclusive. Puede mejorar el rendimiento de las
consultas de accesorios si crea un ndice filtrado en las subcategoras de accesorios como se muestra
en el ejemplo siguiente.
CREATE NONCLUSTERED INDEX FIProductAccessories
ON Production.Product (ProductSubcategoryID, ListPrice)
Include (Name)
WHERE ProductSubcategoryID >= 27 AND ProductSubcategoryID <= 36;

El ndice filtrado FIProductAccessories abarca la consulta siguiente porque los resultados de las consultas
se incluyen en el ndice y el plan de consulta no incluye bsquedas en una tabla base. Por ejemplo, la
expresin de predicado de la consulta ProductSubcategoryID = 33 es un subconjunto del predicado del
ndice filtrado ProductSubcategoryID >= 27 y ProductSubcategoryID <= 36, las
columnas ProductSubcategoryID y ListPrice del predicado de la consulta son ambas columnas de clave del
ndice, y el nombre se almacena en el nivel hoja del ndice como una columna incluida.
SELECT Name, ProductSubcategoryID, ListPrice
FROM Production.Product
WHERE ProductSubcategoryID = 33 AND ListPrice > 25.00 ;

Columnas de clave
Se recomienda insertar un nmero pequeo de columnas incluidas o de clave en la definicin de un
ndice filtrado e incorporar solamente las columnas necesarias para que el optimizador de consultas
elija el ndice filtrado para el plan de ejecucin de consultas. El optimizador de consultas puede elegir
un ndice filtrado para la consulta, independientemente de que cubra la consulta o no. Sin embargo, es
ms probable que el optimizador de consultas elija un ndice filtrado si cubre la consulta.
En algunos casos, un ndice filtrado cubre la consulta sin incluir las columnas en la expresin del ndice
filtrado como columnas incluidas o de clave en la definicin del ndice filtrado. Las instrucciones
siguientes explican los casos en que una columna de la expresin del ndice filtrado debe ser una

14
columna incluida o de clave en la definicin del ndice filtrado. Los ejemplos hacen referencia al ndice
filtrado FIBillOfMaterialsWithEndDate que se cre previamente.
Una columna de la expresin del ndice filtrado no tiene por qu ser una columna incluida o de clave en
la definicin del ndice filtrado cuando la expresin del ndice filtrado es equivalente al predicado de la
consulta y la consulta no devuelve la columna de la expresin del ndice filtrado con los resultados de la
consulta. Por ejemplo, FIBillOfMaterialsWithEndDate cubre la consulta siguiente porque el predicado de
consulta es equivalente a la expresin del filtro, y EndDate no se devuelve con los resultados de la
consulta. FIBillOfMaterialsWithEndDate no necesita EndDate como una columna incluida o de clave en la
definicin del ndice filtrado.
SELECT ComponentID, StartDate FROM Production.BillOfMaterials
WHERE EndDate IS NOT NULL;
Una columna de la expresin del ndice filtrado debe ser una columna incluida o de clave de la
definicin del ndice filtrado cuando el predicado de la consulta usa la columna en una comparacin no
equivalente a la expresin del ndice filtrado. Por ejemplo, FIBillOfMaterialsWithEndDate es vlido para la
consulta siguiente porque selecciona un subconjunto de filas del ndice filtrado. Sin embargo, no cubre
la consulta siguiente porque EndDate se utiliza en la comparacin EndDate > '20040101', que no es
equivalente a la expresin del ndice filtrado. El procesador de consultas no puede ejecutar esta
consulta si no busca los valores de EndDate. Por tanto, EndDate debe ser una columna incluida o de
clave de la definicin del ndice filtrado.
SELECT ComponentID, StartDate FROM Production.BillOfMaterials
WHERE EndDate > '20040101';
Una columna de la expresin del ndice filtrado debe ser una columna incluida o de clave en la
definicin del ndice filtrado si la columna est en el conjunto de resultados de la consulta. Por
ejemplo, FIBillOfMaterialsWithEndDate no atiende la consulta siguiente porque devuelve la
columna EndDate en los resultados de la consulta. Por tanto, EndDate debe ser una columna incluida o
de clave de la definicin del ndice filtrado.
SELECT ComponentID, StartDate, EndDate FROM Production.BillOfMaterials
WHERE EndDate IS NOT NULL;
La clave de ndice clster de la tabla no tiene por qu ser una columna incluida o de clave de la
definicin del ndice filtrado. La clave de ndice cluster se incluye de forma automtica en todos los
ndices no clster, incluidos los ndices filtrados.
Operadores de conversin de datos en el predicado de filtro
Si el operador de comparacin especificado en la expresin del ndice filtrado del ndice filtrado
produce una conversin de datos implcita o explcita, se producir un error cuando la conversin se
realice en el lado izquierdo de un operador de comparacin. Una posible solucin es escribir la
expresin del ndice filtrado con el operador de conversin de datos (CAST o CONVERT) en el lado
derecho del operador de comparacin.
En el ejemplo siguiente se crea una tabla con varios tipos de datos.
USE AdventureWorks2012;
GO
CREATE TABLE dbo.TestTable (a int, b varbinary(4));
En la siguiente definicin del ndice filtrado, la columna b se convierte implcitamente en un tipo de
datos enteros para que se pueda comparar con la constante 1. Esto genera el mensaje de error 10611
porque la conversin se produce en el lado izquierdo del operador del predicado filtrado.
CREATE NONCLUSTERED INDEX TestTabIndex ON dbo.TestTable(a,b)
WHERE b = 1;
La solucin consiste en convertir la constante del lado derecho de forma que sea del mismo tipo que la
columna b, tal como se muestra en el ejemplo siguiente:
CREATE INDEX TestTabIndex ON dbo.TestTable(a,b)
WHERE b = CONVERT(Varbinary(4), 1);
Cuando se mueve la conversin de datos del lado izquierdo al lado derecho de un operador de
comparacin, es posible que cambie el significado de la conversin. En el ejemplo anterior, cuando se
agreg el operador CONVERT en el lado derecho, la comparacin cambi de una comparacin de
enteros a una comparacin varbinary .
15
16