He estado ejecutando una herramienta de indexación automática en nuestra base de datos MS SQL (modifiqué un script originario de Microsoft que mira las tablas de estadísticas de índice: indexación automática automatizada ). De las estadísticas, ahora tengo una lista de recomendaciones para los índices que deben crearse.

Editar: Los índices descritos anteriormente toman información de los DMV que le indican qué utilizaría el motor de la base de datos para los índices si estuvieran disponibles y los scripts toman las recomendaciones de la parte x superior (por búsquedas, impacto en el usuario, etc.) y las ponen en una tabla.

(Editar arriba parcialmente tomado de la respuesta de Larry Coleman a continuación para aclarar lo que están haciendo los guiones)

Como soy nuevo en administración de bases de datos, y después de haber realizado una búsqueda rápida en la red, soy reacio a dar el paso y agregar ciegamente los índices recomendados. Sin embargo, al no tener experiencia en el campo, estoy buscando algunos consejos sobre cómo determinar si las recomendaciones son necesarias o no.

¿Necesito ejecutar el Analizador de SQL, o es mejor examinar el código que consulta las tablas? ¿Y tienes algún otro consejo?

Utilizo los scripts de análisis de índice de Jason Strate (ubicación anterior) . Le indican cuánto se utilizan sus índices existentes, así como la cantidad de índices faltantes que se habrían utilizado. Por lo general, no agrego índices a menos que constituyan más del 5 o 10% de las consultas en una tabla.

Sin embargo, lo más importante es asegurarse de que la aplicación responda lo suficientemente rápido para los usuarios.

Actualización: artículos de blog de análisis de índice de Jason Strate para scripts más nuevos (Nueva ubicación)

Actualización doble: en estos días, uso sp_BlitzIndex® al realizar el análisis de índice.

Hay algunos conceptos y términos que es importante entender cuando se trata de índices. Las búsquedas, escaneos y búsquedas son algunas de las formas en que los índices se utilizarán a través de sentencias select. La selectividad de las columnas clave es integral para determinar cuán efectivo puede ser un índice.

Una búsqueda ocurre cuando el Optimizador de consultas de SQL Server determina que la mejor manera de encontrar los datos que ha solicitado es escaneando un rango dentro de un índice. Las búsquedas generalmente ocurren cuando una consulta está "cubierta" por un índice, lo que significa que los predicados de búsqueda están en la clave de índice y las columnas mostradas están en la clave o incluidas. Un escaneo ocurre cuando el Optimizador de consultas de SQL Server determina que la mejor manera de encontrar los datos es escanear todo el índice y luego filtrar los resultados. Una búsqueda generalmente ocurre cuando un índice no incluye todas las columnas solicitadas, ya sea en la clave de índice o en las columnas incluidas. El optimizador de consultas usará la clave agrupada (contra un índice agrupado) o el RID (contra un montón) para "buscar" las otras columnas solicitadas.

Por lo general, las operaciones de búsqueda son más eficientes que los escaneos, debido a la consulta física de un conjunto de datos más pequeño. Hay situaciones en las que este no es el caso, como un conjunto de datos inicial muy pequeño, pero que va más allá del alcance de su pregunta.

Ahora, usted preguntó cómo determinar qué tan efectivo es un índice, y hay algunas cosas a tener en cuenta. Las columnas de clave de un índice agrupado se denominan clave de agrupación. Así es como los registros se hacen únicos en el contexto de un índice agrupado. Todos los índices no agrupados incluirán la clave agrupada de forma predeterminada, para realizar búsquedas cuando sea necesario. Todos los índices se insertarán, actualizarán o eliminarán de cada instrucción DML respectiva. Dicho esto, es mejor equilibrar las ganancias de rendimiento en las declaraciones seleccionadas con los resultados de inserción en las declaraciones de inserción, eliminación y actualización.

Para determinar qué tan efectivo es un índice, debe determinar la selectividad de sus claves de índice. La selectividad se puede definir como un porcentaje de registros distintos al total de registros. Si tengo una tabla [persona] con 100 registros totales y la columna [nombre_nombre] contiene 90 valores distintos, podemos decir que la columna [nombre_nombre] es 90% selectiva. Cuanto mayor sea la selectividad, más eficiente será la clave de índice. Teniendo en cuenta la selectividad, es mejor poner las columnas más selectivas primero en su clave de índice. Usando mi ejemplo anterior de [persona], ¿qué pasa si tenemos una columna [apellido_nombre] que fue selectiva en un 95%? Nos gustaría crear un índice con [apellido_nombre], [nombre_nombre] como clave de índice.

Sé que esta fue una respuesta un tanto larga, pero realmente hay muchas cosas que intervienen para determinar qué tan efectivo será un índice, y muchas cosas con las que debe sopesar cualquier aumento de rendimiento.

Recientemente descubrí un fantástico script gratuito de la gente de BrentOzar Unltd http://www.brentozar.com/blitzindex/

Esto hace un buen análisis de qué índices existen, con qué frecuencia se usan y con qué frecuencia el motor de búsqueda está buscando un índice que no existe.

Su orientación es generalmente buena. A veces se vuelve un poco sugestivo de ideas. En general, he hecho lo siguiente hasta ahora:

• Se eliminaron los índices que NUNCA se han leído (o tal vez menos de 50 veces al mes).
• Se agregaron los índices más obvios en claves y campos foráneos. Sé que usamos mucho.

¡No he agregado todos los índices recomendados, y volví una semana más tarde para encontrar que ya no se recomiendan ya que el motor de consulta está usando algunos de los otros índices nuevos!

En general, debe evitar los índices en:

• Tablas muy pequeñas (menos de 50 a 200 registros): a menudo el motor de consulta es más rápido si escanea la tabla en lugar de cargar el índice, leerlo, procesarlo, etc.
• Evite los índices en columnas con baja cardinalidad ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) en la primera columna mencionada. Por ejemplo, indexar un campo de género (M / F) es de muy poca utilidad, es tan práctico escanear la tabla y encontrar el ~ 50% que coincida. Si aparece en la lista después de algo más específico en el índice (p. Ej., [Fecha de nacimiento, sexo]), eso es mejor; es posible que desee que todos los hombres nazcan en un período de tiempo determinado.

Los índices agrupados son buenos, normalmente se basan en su clave principal. Ayudan al motor de la base de datos a poner los datos en el disco en buen estado. Es muy esencial comprender esto para las tablas más grandes, ya que un buen índice agrupado a menudo reduce el espacio que ocupa la tabla.

He reducido algunas tablas de 900 MB a 400 MB, solo porque eran montones no construidos de antemano. http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx

Reorganizar / Reconstruir

Debería buscar verificar índices fragmentados. Un poco de fragmentación está bien, ¡no te obsesiones! http://technet.microsoft.com/en-us/library/ms189858.aspx ¡ Conozca la diferencia entre reorganizar y reconstruir!

Revisar regularmente

Las consultas cambian, los volúmenes de datos cambian, se agregan nuevas características, se eliminan las antiguas. ¡Debería mirarlos una vez al mes (o más a menudo si tiene grandes volúmenes) y buscar dónde puede ayudar a la base de datos!

Cuántos

En un video reciente, Brent recomienda (típicamente) no más de 5 índices en una tabla con mucha escritura (por ejemplo, tabla de pedidos), y no más de 10 si se lee mucho más de lo que se escribe (es decir, tabla de registro para análisis) http: / /www.youtube.com/watch?v=gOsflkQkHjg

En general

¡Depende!

Su kilometraje varía según la base de datos. Cubra lo obvio (apellido del empleado, fecha de pedido, etc.) en sus tablas más grandes (ahora / futuras). Monitoree, revise y ajuste según sea necesario. Debería ser parte de su lista de verificación de rutina al administrar su (s) base (s) de datos :)

¡Espero que esto ayude!

Normalmente, uno tiene una carga de trabajo específica (consultas) y prueba cuidadosamente el impacto de cada nuevo índice en la carga de trabajo. Este proceso iterativo siempre debe incluir un análisis cuidadoso de los planes de ejecución, que revelaría qué índices se utilizan. El tema de analizar una consulta es largo, y comenzar con el capítulo dedicado de MSDN Analizar una consulta es una buena apuesta.

A veces, cuando la carga de trabajo es demasiado compleja o el conocimiento del diseño de la base de datos es incompleto, se utiliza el Asesor de ajuste de motor de base de datos , que realiza un análisis automático de su carga de trabajo y propone algunos índices. Las propuestas deben, por supuesto, analizarse cuidadosamente y el impacto debe medirse de inmediato.

Entonces, si sigue mi idea, agregar un índice y medir el impacto es realmente solo un caso de prueba A / B : ejecuta su carga de trabajo sin el índice como una línea base, luego la ejecuta con el índice, mide y compara con la línea base y luego decida, en función de las métricas observadas y medidas, si el impacto es beneficioso. La carga de trabajo es mejor un conjunto de pruebas de buena calidad, pero también puede ser una reproducción de una carga de trabajo capturada, consulte Cómo: reproducir un archivo de rastreo .

Una respuesta más sintética es mirar la sys.dm_db_index_usage_statsvista y ver cómo se utilizan los índices, pero ese suele ser un enfoque para hacer análisis in situ en una carga de trabajo desconocida (es decir, un consultor llamado para ayudar probablemente comenzaría con esto).

A partir de SQL 2005, SQL Server tiene DMV que le indican qué utilizaría el motor de la base de datos para los índices si estuvieran disponibles. Las vistas pueden indicarle qué columnas deberían ser columnas clave, qué columnas deberían incluirse y, lo que es más importante, cuántas veces se habría utilizado el índice.

Un buen enfoque sería ordenar la consulta de índices faltantes por número de búsquedas, y considerar agregar primero los índices superiores.

^{Ver también: los documentos oficiales de MS DMV}

Depende de cómo se use esa tabla. por ejemplo, digamos que tengo una tabla que se lee muchas veces, pero las actualizaciones e inserciones son raras. Además, siempre consulto la tabla en alguna columna de clave externa. Tendrá sentido crear un índice (no agrupado) sobre esa clave externa para acelerar las consultas de lectura. Pero la desventaja es que su inserción, la actualización se volverá lenta.

Hay pocas consultas de estadísticas que indican cuánto tiempo llevan las consultas. Comience con los más lentos. Si el predicado de consulta no tiene índice, crear uno ayudará.