Gua de diseo de ndices de SQL Server

Este tema an no ha recibido ninguna valoracin - Valorar este tema 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.

Se aplica a: SQL Server 2005 a SQL Server 2012, a menos que se especifique lo contrario.
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 Directrices generales para disear ndices Directrices para disear ndices clster Directrices para disear ndices no clster Directrices para disear ndices nicos Directrices generales para disear ndices filtrados Lecturas adicionales

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 ndices de almacn de columnas. 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, vea 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 Tablas e ndices con particiones. 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.

Directrices generales para disear ndices

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 las bases de datos

Cuando disee un ndice, tenga en cuenta las siguientes directrices acerca de la base de datos: 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. 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 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 Asistente para la optimizacin de motor de base de datos.

Consideraciones sobre las 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, b y cpuede 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 las 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, vea 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, vea 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 Estadsticas. 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.

Tenga en cuenta el orden de las columnas si el ndice va a contener varias columnas. La columna que se utiliza 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 ndices en columnas calculadas.

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 empleaTable_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: 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, vea Tablas e ndices con particiones.

Directrices para disear el criterio de ordenacin de los 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 RejectedQtyde 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 BYORDER 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. [Arriba]

Directrices para disear ndices clster

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.

Nota

Cuando crea una restriccin PRIMARY KEY, se crea automticamente un ndice nico en las column es clster; sin embargo, puede especificar un ndice no clster cuando crea la restriccin.
Se pueden utilizar en consultas por rango. 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.

Consideraciones sobre las 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 las 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, FirstName y 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 ProductID mejorara las consultas en las que se especifica una bsqueda secuencial, como WHERE ProductID BETWEEN 980 and 999. 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. [Arriba]

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 clster tienen una fila en sys.partitions, con index_id >1 para cada particin utilizada 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. 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. 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, A y 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 las claves 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
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 las claves 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 (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 permiten todos los tipos de datos, excepto text, ntext e image. Las columnas calculadas que son deterministas y precisas o imprecisas pueden ser columnas incluidas. Para obtener ms informacin, vea ndices en columnas calculadas. Al igual que con las columnas de clave, las columnas calculadas derivadas de los tipos de datos image, ntext y 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 columnasvarchar(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, nvarchar o 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 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. [Arriba]

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 tablaHumanResources.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, FirstName y 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. [Arriba]

Directrices generales 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 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: SQL Server 2008 a SQL Server 2012.

Los ndices filtrados pueden proporcionar las siguientes ventajas respecto a los ndices de tabla completa: Mejor rendimiento de las consultas y mayor calidad del plan 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. Menor costo de mantenimiento de ndices 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 reducidos de almacenamiento de ndices 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. 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 Crear ndices filtrados.

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 ProductSubcategoryID que, 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, Class y 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 = 33es 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 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 lo tanto, EndDatedebe 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.