17

BASES DE DATOS

INDICES
Un ndice es una estructura almacenada 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. Una tabla o una vista puede contener como los ms importantes, los siguientes tipos de ndices: Los Clustered Indexes son ndices que controlan el orden fsico de las filas en la tabla, por lo cual solo puede existir uno para cada tabla. Los NonClustered indexes son ndices que mantienen un sub conjunto de las columnas de la tabla en orden. Estos ndices no modifican el orden de las filas de la tabla, en lugar de esto mantienen una lista ordenada de referencias a filas de la tabla original. Para ilustrar la diferencia entre estos 2 tipos de ndices podemos decir que las pginas blancas de la gua telefnica tienen un clustered index por Apellido y Nombre, con lo cual puedo buscar de forma muy eficiente el nmero de telfono de una persona si conozco sus apellidos y su nombre, una vez que lo encuentro obtendr su nmero de telfono en forma inmediata pues el numero est al lado del nombre. En el caso de las pginas amarillas de la gua telefnica la forma de buscar es un poco distinta, en este caso busco por categora. Primero busco en un ndice, el cual me indica en qu pgina se encuentra la lista de empresas que satisfacen la condicin que busco. Esto mismo es lo que pasa cuando utilizo un ndice NonClustered; una vez que encuentro lo que quiero en el ndice debo ir a leer la fila especfica para obtener el resto de los datos.

INDICE AGRUPADO (CLUSTERED)

Se refiere a una relacin de la posicin fsica de la fila de datos de la tabla en las pginas de almacenamiento. Slo puede haber un ndice agrupado por cada tabla, porque las filas de datos slo pueden estar ordenadas de una forma (desde el punto de vista fsico). o Por ejemplo: los libros en una estantera solo pueden ser fsicamente dispuestos en un orden: por tamao, por autor, por tema
o

Bases de Datos

Ing. Rosa Navarrete

17 Los ndices agrupados ordenan y almacenan las filas de los datos de la tabla o vista de acuerdo con los valores de la clave del ndice. Son columnas incluidas en la definicin del ndice. o La nica ocasin en la que las filas de datos de una tabla estn ordenadas es cuando la tabla contiene un ndice agrupado (tabla agrupada). Si una tabla no tiene un ndice agrupado, sus filas de datos estn almacenadas en una estructura sin ordenar denominada montn.
o

INDICES NO AGRUPADOS (NONCLUSTERED)

Los ndices no agrupados tienen una estructura separada de las filas de datos. Un ndice no agrupado contiene los valores de clave de ndice no agrupado y cada entrada de valor de clave tiene un puntero a la fila de datos que contiene el valor clave. Por ejemplo: imagine que usted escribe distintas formas de ordenamiento de los libros ubicados en la estantera; por autor, por ttulo, etc. Cada forma de ordenamiento sera un ndice no agrupado. o El puntero de una fila de ndice no agrupado hacia una fila de datos se denomina localizador de fila. La estructura del localizador de filas depende de si las pginas de datos estn almacenadas en un montn o en una tabla agrupada. Si estn en un montn, el localizador de filas es un puntero hacia la fila. Si estn en una tabla agrupada, el localizador de fila es la clave de ndice agrupada.
o

Tanto los ndices agrupados como los no agrupados pueden ser nicos. Esto significa que (dos filas no pueden tener el mismo valor para la clave de ndice; de lo contrario, el ndice no es nico y varias filas pueden compartir el mismo valor de clave). Los ndices se crean automticamente cuando las restricciones PRIMARY KEY y UNIQUE se definen en las columnas de tabla.

DIRECTRICES PARA DISEAR INDICES CLUSTERED

Por regla general, 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 del empleado basndose en el nmero de Id. del empleado. Tambin se podra crear un ndice clster en las columnas LastName y FirstName, ya que los registros de empleados se agrupan y se consultan con frecuencia de esta forma y la

Bases de Datos

Ing. Rosa Navarrete

17 combinacin de estas columnas seguira proporcionando un alto grado de diferencia. Se tiene acceso a ellas de forma secuencial Por ejemplo, un Id. de producto identifica de forma exclusiva los productos; un ndice clster en ProductID mejorara las consultas donde 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 definen como IDENTITY, ya que la columna va a ser nica en la tabla 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 agrupados no se recomiendan en: Columnas sometidas a cambios frecuentes Esto provoca que se mueva toda la fila, ya que el 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 agrupados como claves de bsqueda. Los ndices no agrupados 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 agrupado

DIRECTRICES PARA DISEAR INDICES NONCLUSTERED

Un ndice no agrupado contiene los valores de clave del ndice y localizadores de fila que apuntan a la ubicacin de almacenamiento de los datos de tabla. 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

Bases de Datos

Ing. Rosa Navarrete

17 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.
Gran nmero de valores distintos, como combinaciones de nombres y

apellidos, si se utiliza un ndice clster para otras columnas.

Se utilizan en clusulas JOIN o GROUP BY.

Crean varios ndices no agrupados 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 subconjunto bien definido de filas en una tabla grande.

devuelven

un

Contienen columnas que suelen incluirse en las condiciones de bsqueda

de una consulta, como la clusula WHERE, que devuelven coincidencias exactas.

USO DE NDICES
Sin lugar a dudas, el desempeo de una aplicacin est directamente relacionado al buen o mal diseo de los ndices de la base de datos. Para demostrar esto tomemos como ejemplo la tabla de usuarios de un sistema cualquiera, la cual tiene la siguiente estructura:

Esta tabla no tiene ningn ndice creado, por lo cual SQL Server tratar la tabla como un HEAP (una estructura de datos que almacena la posicin fsica en la que se almacen cada nueva fila dentro de las pginas asignadas a la tabla). Puesto que esta tabla no tiene ningn tipo de ndice, es bastante eficiente para agregar nuevas filas a la tabla pero muy ineficiente para encontrar una fila especfica, esto se debe a que es necesario leer toda la tabla para obtener el resultado deseado. Para ilustrar esto, realicemos lo siguiente:

Bases de Datos

Ing. Rosa Navarrete

17 Creamos una base de datos de trabajo, llamada bdusuarios: use master go SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO create database bdusuarios go use bdusuarios go /* ============================================= Store Procedure para crear registros en la tabla Usuarios para pruebas Utiliza 'SHA1' como algoritmo hash para realizar el hash de la entrada Se probar para insertar 10.000 registros utilizando el procedimiento almacenado CrearUsuarios, los usuarios no estn activos y su fecha de creacin est en los ltimos 600 das. ============================================= */ drop procedure [dbo].[CrearUsuarios] go CREATE PROCEDURE [dbo].[CrearUsuarios] @n int, @nInactivos int, @nDias int AS BEGIN SET NOCOUNT ON; DECLARE @x INT = 0 DECLARE @name varchar(20) DECLARE @pass varchar(30) DECLARE @fecha datetime DECLARE @activo bit DELETE FROM Usuarios WHILE (@x < @n) BEGIN SET @name = 'USUARIO' + CAST(@x as varchar) SET @pass = 'PASS' + CAST(@x as varchar)

Bases de Datos

Ing. Rosa Navarrete

17 SET @activo = (@x % (@n/@nInactivos)) SET @fecha = DATEADD(DAY,(@n-@X)/@nDias,GETDATE()) INSERT Activo) VALUES (@name, HASHBYTES('SHA1', 'RN123' + @pass), @fecha, @activo) SET @x = @x + 1 END END GO exec sp_helptext CrearUsuarios exec CrearUsuarios 100000, 10000, 600 INTO Usuarios (Username, Password, FechaCreacion,

Ahora realicemos una consulta para validar el usuario al inicio de sesin del sistema. SELECT Password, Activo FROM Usuarios WHERE Username = 'Usuario123' La respuesta probablemente funcione bastante rpido, ya que al recin haber creado los datos, todas estas filas estn en memoria, pero veamos el plan de ejecucin de esta consulta presionando el botn (Incluir plan de ejecucin real) de la barra de herramientas del SQL Server Management Studio y luego ejecutando la misma consulta.

Al pasar el mouse sobre el primer elemento de la izquierda se puede observar el costo de la consulta.

Bases de Datos

Ing. Rosa Navarrete

17

El costo estimado de la consulta es de 0.648838 y la forma de resolverlo fue un Table Scan, lo que implica leer toda la tabla. Para obtener ms informacin sobre el acceso a los datos requeridos para resolver la consulta ejecutamos lo siguiente, antes de la consulta: CHECKPOINT DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS SET STATISTICS IO ON SELECT Password, Activo FROM Usuarios WHERE Username = 'Usuario123' SET STATISTICS IO OFF Lo primero que pasa al ejecutar esta consulta es que SQL Server escribe todos los cambios pendientes al disco, la segunda instruccin elimina todos los datos que tiene en memoria. La combinacin de estas dos instrucciones obliga a SQL Server a leer todo desde disco nuevamente, es importante tener en cuenta que al ejecutar DBCC DropCleanBuffers se produce un fuerte impacto en el desempeo de todos los usuarios, por lo que no se debe utilizar en servidores de produccin. La tercera instruccin nos permite obtener informacin sobre las lecturas de datos requeridas para contestar una consulta. El resultado que se obtiene en el rea de mensajes es:

Bases de Datos

Ing. Rosa Navarrete

17 (1 filas afectadas) Tabla 'Usuarios'. Recuento de exmenes 1, lecturas lgicas 724, lecturas fsicas 8, lecturas anticipadas 728, lecturas lgicas de LOB 0, lecturas fsicas de LOB 0, lecturas anticipadas de LOB 0. (1 filas afectadas) Esto nos dice que se accedi a la tabla Usuarios, se hizo una lectura completa de la tabla 1 vez, lo que equivale a 724 pginas ledas, como cada pgina pesa 8Kb, 724 * 8kb es igual a 5792 Kb, casi 6 Mb, precisamente lo mismo que pesa la tabla completa. Las lecturas fsicas son las pginas que no se encontraban en memoria cuando SQL Server las necesitaba, en este caso fueron 8, algo extrao ya que vaciamos el cache antes de ejecutar la consulta por lo cual no debera existir ninguna pgina en memoria, pero SQL Server es ms inteligente y cada vez que tiene que leer pginas desde el disco, lo cual es una operacin muy costosa, lee tambin otras pginas cercanas que puedan ser tiles para responder la consulta que solicit la lectura. En este caso SQL Server fue capaz de Leer 728 pginas utilizando este mecanismo de lecturas anticipadas (read-ahead). Las lob o Large Object Block, son operaciones relacionadas a datos que no se guardan junto con la fila como los campos de tipo TEXT, IMAGE y los tipos de datos que sobrepasen los 8000 bytes de la pgina. En este caso no hay operaciones de este tipo. UTILIZANDO INDICES Para mejorar el desempeo de las consultas se utilizan ndices. Veamos qu pasa cuando agregamos un ndice a la columna Username de la tabla Usuarios que creamos. El ndice ser Non-Clustered y nico puesto que no podemos tener ms de un usuario con el mismo nombre. create unique nonclustered index index_username on Usuarios (Username) Volvemos a ejecutar la misma consulta: SELECT Password, Activo FROM Usuarios WHERE Username = 'Usuario123'

Bases de Datos

Ing. Rosa Navarrete

17

El plan de ejecucin es un poco ms complicado pero esta consulta es 100 veces menos costosa que la anterior. (anterior: 0.648838, actual: 0,0065704). Ahora la consulta utiliza el ndice para encontrar el RID, que es el identificador de la fila, con este RID hace una bsqueda en la tabla de tipo heap (RID Lookup). Volviendo a utilizar: CHECKPOINT DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS SET STATISTICS IO ON SELECT Password, Activo FROM Usuarios WHERE Username = 'Usuario123' SET STATISTICS IO OFF Se obtiene: (1 filas afectadas) Tabla 'Usuarios'. Recuento de exmenes 0, lecturas lgicas 4, lecturas fsicas 4, lecturas anticipadas 0, lecturas lgicas de LOB 0, lecturas fsicas de LOB 0, lecturas anticipadas de LOB 0. (1 filas afectadas)

Bases de Datos

Ing. Rosa Navarrete

17 Esta reduccin de costo se explica por la cantidad de accesos a datos que esta consulta requiere, puesto que estos bajan desde 724 a solo 4 pginas lo que equivale 32 kb de datos contra 5792 kb, que eran necesarios antes de la creacin del ndice. Veamos otra alternativa, si utilizamos un clustered index en lugar de un noncluster index no ser necesario el lookup, por lo que el acceso ser ms eficiente. -- Borramos el ndice nonclustered drop index index_username on Usuarios -- Creamos el ndice clustered create unique clustered index index_username on Usuarios (Username)

Y el acceso se ve as: CHECKPOINT DBCC DROPCLEANBUFFERS WITH NO_INFOMSGS SET STATISTICS IO ON SELECT Password, Activo FROM Usuarios WHERE Username = 'Usuario123' SET STATISTICS IO OFF

Bases de Datos

Ing. Rosa Navarrete

17 (1 filas afectadas) Tabla 'Usuarios'. Recuento de exmenes 0, lecturas lgicas 3, lecturas fsicas 2, lecturas anticipadas 0, lecturas lgicas de LOB 0, lecturas fsicas de LOB 0, lecturas anticipadas de LOB 0. (1 filas afectadas) Como se puede ver el costo de esta consulta ahora es menor, casi a la mitad que con el ndice non-clustered y en lugar de 4 lecturas lgicas tenemos slo 3. Es importante destacar que segn Comparing Tables Organized with Clustered Indexes versus Heaps, es siempre recomendable utilizar tablas que utilicen un Cluster index en lugar de tablas que solo utilicen ndices non-cluster.

COLUMNAS INCLUIDAS
A partir del SQL Server 2005 se agreg una nueva funcionalidad a los ndices non-clustered llamada columnas incluidas; estas columnas no son parte de la llave ndice, por lo que no se mantienen ordenadas dentro del ndice y como consecuencia de esto solo es necesario almacenar su valor en el nodo hoja del ndice. Las columnas incluidas tienen varias ventajas:

Al utilizar columnas incluidas en el ndice es posible superar la limitacin de los 900 bytes para la llave del ndice, manteniendo un ndice eficiente. Las modificaciones al valor de una columna incluida es ms eficiente que la modificacin de una columna que es parte de la llave del ndice pues estas no requieren ser mantenidas en orden. Es posible crear Covering Indexes, que son ndices que incluyen todas las columnas requeridas para contestar una consulta especfica, que no requieren la bsqueda sobre el clustered index. Este tipo de ndice es igual o ms eficiente que u ndice cluster.

NDICES FILTRADOS
El SQL Server 2008 agreg otra mejora a los ndices non-clustered llamada ndices Filtrados. Estos ndices mantienen ordenados un sub conjunto de las filas de la tabla. El uso ms comn de este tipo de ndices se da cuando queremos crear un ndice sobre una columna que permite valores nulos. Al crear un ndice normal podemos desperdiciar una gran parte del espacio de ndice ordenando filas que tienen un valor nulo. A continuacin se describen algunos ejemplos de casos de uso para estos ndices filtrados:

Bases de Datos

Ing. Rosa Navarrete

17

La columna fecha de trmino de contrato de la tabla empleado contiene una gran cantidad de filas con el valor nulo. Los estados intermedios son buenos candidatos para ser ndices filtrados. Es posible crear un ndice que solo contenga las ordenes de compra recibidas y en proceso, pero no las despachadas.
DE USO DE NDICES

EJEMPLO

La forma ms sencilla de ver la diferencia que puede provocar el uso de ndices es crear una tabla simple y ver el plan de ejecucin de consultas, en ambos casos (con y sin el ndice). Comencemos creando la tabla y agregando algunos valores:
CREATE TABLE [dbo].[Datos1]( [ID] [int] NOT NULL, [Numero] [int]NOT NULL, [Descripcion] [nvarchar](50) NOT NULL, ) INSERT INTO Datos1 ([ID],[Numero],[Descripcion]) INSERT INTO Datos1 ([ID],[Numero],[Descripcion]) INSERT INTO Datos1 ([ID],[Numero],[Descripcion]) INSERT INTO Datos1 ([ID],[Numero],[Descripcion])

VALUES VALUES VALUES VALUES

(1,1,'D1') (2,2,'D2') (3,3,'D3') (4,4,'D4')

Luego iniciaremos una bsqueda y veremos el plan de ejecucin. El plan de ejecucin mostrar de qu manera el query optimizer intentar acceder a los datos durante una consulta, (El query optimizer es el encargado de disear la estrategia del acceso a los datos). Existen varias maneras de ver el plan de ejecucin, utilizaremos en estos ejemplos la forma grafica. Luego de haber ejecutado el script previo deberemos escribir lo siguiente en un query analizer:
SELECT [ID], [Numero], [Descripcion] FROM Datos1 WHERE ID=1

Y luego presionar CTRL+L. Se obtendr un resultado similar a lo siguiente:

Bases de Datos

Ing. Rosa Navarrete

17

Los planes de ejecucin en formato grfico deben leerse de izquierda a derecha y de arriba hacia abajo, y aunque pueden ser extremadamente largos y complejos de leer, en este caso podemos ver el mismo est compuesto por solamente dos iconos y una flecha que los une a ambos. Cada icono representar una operacin y la flecha simbolizar el movimiento de datos entre las dos operaciones, indicndonos que la operacin Table Scan ha tomado los datos que la operacin SELECT procesar, en realidad la operacin SELECT no ha hecho nada en este caso. Este diagrama nos indica que est haciendo internamente el motor de base de datos.
Una operacin Table Scan nos est indicando que el motor ha necesitado recorrer secuencialmente la tabla Datos1 para poder encontrar los registros que cumplan con la condicin pedida. La operacin Table Scan es equivalente a tener un diccionario desordenado donde es necesario recorrerlo secuencialmente hasta encontrar la palabra que deseamos buscar, pero adems la palabra puede existir ms de una vez, as que siempre deberemos recorrerlo hasta la ltima palabra para asegurarnos que hemos encontrado todas las definiciones. Cuando no hay ndices creados la performance de las bsquedas quedan gravemente comprometidas. En contraposicin crearemos un ndice y veremos que cambios se producen en el plan de ejecucin, ejecutaremos la siguiente lnea de cdigo:
CREATE CLUSTERED INDEX IX_1 ON [dbo].[Datos1] (ID)

Donde hemos indicado la creacin de un ndice por la columna ID,(la palabra CLUSTERED indicar que la tabla se ordenar fsicamente por el ndice solicitado, luego veremos que existe otro tipo de ndices que no impone tal condicin.) Si volvemos a ejecutar la consulta anterior, el plan de ejecucin tomar el siguiente formato:

Indicando que en este caso la bsqueda de datos est utilizando el ndice IX_1, de manera que el motor ya no debe recorrer toda la tabla para encontrar los

Bases de Datos

Ing. Rosa Navarrete

17 registros pedidos. Podemos ahora preguntarnos que pasara si adems es necesario realizar bsquedas por otro campo, supongamos por el campo Numero, en este caso no podremos reordenar la tabla fsicamente por Numero, ya que al hacer esto perderamos el orden fsico que ya habamos establecido por el campo ID, es claro que el orden fsico puede establecerse solo para una clave (ya sea compuesta por un solo o varios campos). Para estos casos existen otro tipo de ndices conocidos como ndices non-clustered, ya que no modifican el orden fsico de los registros en la tabla original, estos ndices guardarn en otra estructura una copia de los valores involucrados en la clave y un puntero al registro original de la tabla. Para probar lo antes comentado ejecutaremos el siguiente comando:
CREATE INDEX IX_2 ON [dbo].[Datos1] (Numero)

Y luego veremos el plan de la siguiente bsqueda:

Donde puede verse que el query optimizer ha decidido utilizar el nuevo ndice IX_2. En este ltimo query solo estamos incluyendo a la columna Numero. Si realizara la misma bsqueda pero esta vez con todos los campos, comprobar que el query optimizer habr decidi utilizar el ndice IX_1, y no IX_2; esto debido a que como se estableci previamente, los ndices non-clustered guardan una copia de las claves y un puntero al registro original, de esta manera cuando hemos buscado solamente por Numero el ndice IX_2 es capaz de devolver la informacin solicitada ya que posee el valor de la columna Numero, pero cuando hemos pedido otros datos como ID y Descripcion que no existen en IX_2 el query optimizer ha decidido que es menos costoso recorrer la tabla por IX_1 para devolver los datos que IX_2 no posee. Cuando un ndice non-clustered cubre todos los datos solicitados en la consulta se dice que es un covered-index, el caso contrario no ser un covered-index y el query optimizer deber buscar
Bases de Datos Ing. Rosa Navarrete

17

alguna estrategia para obtener los datos faltantes, obviamente los clustered index son siempre covered index, ya que poseen el registro completo. El query optimizer puede utilizar otras estrategias para obtener los datos faltantes como veremos a continuacin. Si ejecutamos el siguiente cdigo:
DELETE FROM Datos1 DECLARE @C int =1 WHILE @C < 10000 BEGIN INSERT INTO Datos1 ([ID],[Numero],[Descripcion]) VALUES (@C,@C + 1,'D1' + cast(@C as nvarchar(10))) SET @C+=1 END

Donde solamente hemos agregado ms datos y volvemos a ejecutar la consulta anterior veremos lo siguiente:

Ahora el query optimizer ha utilizado nuestro ndice IX_2 pero para recuperar los datos faltantes a requerido efectuar una operacin de Key Lookup extra utilizando el ndice IX_1, para finalmente unir los datos en la operacin Nested Loops. Si creamos un nuevo ndice que cubra todos los datos pedidos de la siguiente forma:
CREATE INDEX IX_3 ON [dbo].[Datos1] (Numero,ID,Descripcion)

No debera sorprendernos el siguiente resultado:

Bases de Datos

Ing. Rosa Navarrete

17

Otra opcin para incluir las columnas restantes es utilizar la sentencia INCLUDE de la siguiente forma:
CREATE INDEX IX_3 ON [dbo].[Datos1] (Numero) INCLUDE (Descripcion, ID)

En el segundo caso, las columnas son agregadas al ndice pero no forman parte del mismo. En ambos tipos de ndices, clustered o non-clustered existe la posibilidad de definirlos como nicos (unique), un ndice nico no admite repeticin de valores, y permite una mayor optimizacin en las bsquedas. Las claves primarias de las tablas estn compuestas por ndices unique que pueden ser o no clustered. En Sql Server 2008 existe adems la posibilidad de crear ndices filtrados, o sea ndices que se aplican solo a un grupo de datos. Para probarlo podemos eliminar los ndices IX_2 e IX_3 y crear un nuevo ndice IX_4 filtrado, las siguientes lneas de cdigo efectuan estas operaciones:
DROP INDEX IX_2 ON [dbo].[Datos1] DROP INDEX IX_3 ON [dbo].[Datos1] CREATE INDEX IX_4 ON [dbo].[Datos1] (Numero,ID,Descripcion) WHERE Numero < 100

De esta forma el ndice IX_4 ser aplicable para algunas condiciones solamente, por ejemplo si ejecutamos el siguiente query:

Bases de Datos

Ing. Rosa Navarrete

17

El query optimizer ha decidido emplear IX_4 mientras que en el caso de:

Ha optado por IX_1.

Un ndice es una estructura de la tabla utilizada por SQL SERVER para proveer un rpido acceso a los registros de la tabla, basado en valores de una o ms columnas. Contiene valores de datos y punteros a los registros donde estos valores aparecen. VENTAJAS DE INDEXAR:

Fuerza la unicidad de registros Acelera los join Asegura el chequeo de integridad referencial Acelera la recuperacin de datos esparcidos Acelera las operaciones de GROUP BY y ORDER BY

DESVENTAJAS DE INDEXAR :

Tiempo invertido en la creacin de los ndices

Bases de Datos

Ing. Rosa Navarrete

17

Toma espacio en el disco, se necesita espacio para cada ndice que se crea Las modificaciones de datos pueden tomar ms tiempo; insert, update, delete alteran los ndices.

CUANDO SE RECOMIENDA INDEXAR:

Las claves primarias deben ser indexadas (por default) Crear un ndice en cada columna sobre la que se necesite realizar bsquedas frecuentemente. Las claves forneas tambin deben ser indexadas, para ayudar a encontrar la informacin ms eficientemente. Una columna que se accesa frecuentemente para ordenamiento, debe tener un ndice clustered para que SQLSERVER tome ventaja del ordenamiento del ndice Las columnas que se utilizan regularmente en los JOIN, deben ser indexadas para acelerar la juntura. Una columna que a menudo es considerada para rangos de valores.

CUANDO NO ES RECOMENDABLE INDEXAR:

Cuando una columna se referencia muy poco en las consultas Cuando una columna contiene pocos valores nicos. Cuando una columna contiene texto, imgenes o campos bit. Cuando el rendimiento en UPDATE es ms importante que el rendimiento en SELECT.

TIPOS DE INDICES: UNIQUE Crea un ndice con entradas de valor nico. No admite valores duplicados y los verifica en insert, update, delete. CLUSTERED Crea un ndice agrupado en el mismo orden fsico de las filas en el almacenamiento. Solo un ndice por tabla puede declararse como CLUSTERED. NONCLUSTERED Crea un ndice que representa un orden lgico de las tablas. Pueden existir hasta 249 ndices NONCLUSTERED por tabla.

Bases de Datos

Ing. Rosa Navarrete