índice agrupado de SQL Server - Orden del Índice Pregunta

Question

Tengo una tabla de este modo:

keyA keyB data 

KEYA y keyb juntos son únicos, son la clave principal de mi mesa y constituyen un índice agrupado.

Existen 5 valores posibles de keyB pero un número ilimitado de valores posibles de keyA ,. keyB generalmente se incrementa.

Por ejemplo, los datos siguientes se pueden pedir de 2 maneras, dependiendo de lo que se ordena la primera columna clave:

keyA keyB data 
A 1 X 
B 1 X 
A 3 X 
B 3 X 
A 5 X 
B 5 X 
A 7 X 
B 7 X 

o

keyA keyB data 
A 1 X 
A 3 X 
A 5 X 
A 7 X 
B 1 X 
B 3 X 
B 5 X 
B 7 X 

¿Es necesario decir el índice agrupado cuál de las columnas clave tienen menos valores posibles para permitirle ordenar primero los datos por ese valor? ¿O no importa en términos de rendimiento que se ordena primero?

Answer 1

Primero debe solicitar su índice agrupado compuesto con la columna más selectiva. Esto significa la columna con los valores más distintos en comparación con el recuento total de filas.

"Los índices B * TREE mejoran el rendimiento de las consultas que seleccionan un pequeño porcentaje de filas de una tabla." http://www.akadia.com/services/ora_index_selectivity.html?

Este artículo es para Oracle, pero sigue siendo relevante.

Además, si tiene una consulta que se ejecuta constantemente y devuelve pocos campos, puede considerar crear un índice compuesto que contenga todos los campos; no tendrá que acceder a la tabla base, sino que extraerá datos del índice .

Es importante recordar el comentario de ligget78 sobre asegurarse de mencionar la primera columna en un índice compuesto.

Answer 2

Lo mejor que puede hacer es probar ambas soluciones y medir el tiempo de ejecución.

En mi experiencia, el ajuste del índice es casi una ciencia exacta.

Tal vez tener keyb antes KEYA en el orden de las columnas de índice sería mejor

Answer 3

Creo que las órdenes SQL Server exactamente como lo cuentas. Supone que usted sabe mejor cómo acceder a su índice.

En cualquier caso, diría que es una buena idea siempre que sea posible especificar lo que quiere exactamente en lugar de esperar que la base de datos lo resuelva.

También puede intentarlo de ambas formas, ejecutar una serie de consultas representativas y luego comparar los planes de ejecución generados para determinar cuál es la mejor para usted.

Answer 4

Si crea un índice (sin agrupar o no) con (claveA, tecla B), así es como se ordenarán los valores, p. primera clave A, luego tecla B (este es el segundo caso en su pregunta). Si lo quiere al revés, necesita especificar (keyB, keyA).

Podría importar en cuanto a rendimiento, depende de su consulta, por supuesto. Por ejemplo, si tiene un índice (keyA, keyB) y la consulta parece WHERE keyB = ... (sin mencionar la clave A), entonces el índice no puede utilizarse.

Answer 5

Especifique las columnas en el orden en el que normalmente desea ordenarlas en informes y consultas.

Sin embargo, sería cauteloso al crear un índice agrupado en varias columnas. Dependiendo de qué tan amplio sea esto, podría tener un gran impacto en el tamaño de cualquier otro índice que cree, porque todos los índices no agrupados contienen el valor del índice agrupado. También las filas tienen que ser reordenadas si los valores cambian con frecuencia y es mi experiencia que las claves no suplentes tienden a cambiar más frecuentemente. Por lo tanto, crear esto como un índice agrupado no agrupado podría consumir mucho más tiempo de los recursos del servidor si tiene valores que es probable que cambien. No digo que no deba hacer esto, ya que no sé qué tipo de datos contienen realmente sus columnas (aunque sospecho que son más complejas que A1, a2, etc.); Estoy diciendo que necesitas pensar sobre las ramificaciones de hacerlo. Probablemente sería una buena idea leer a fondo BOL acerca de los índices no agrupados de vice clúster antes de comprometerse a hacerlo.

Answer 6

Como han dicho otros, el orden se basa en cómo lo especifique en el script de creación del índice (o restricción PK). Una cosa sobre los índices agrupados es que hay mucho que tener en cuenta.

Puede obtener un mejor rendimiento general utilizando su índice agrupado en algo que no sea el PK. Por ejemplo, si está escribiendo un sistema financiero y los informes casi siempre se basan en la fecha y hora de una actividad (toda la actividad del año pasado, etc.), entonces un índice agrupado en esa columna de fecha podría ser mejor. Como dice HLGEM, la clasificación también se puede ver afectada por la selección del índice agrupado.

Los índices agrupados también pueden afectar a las inserciones más que a otros índices. Si tiene un gran volumen de insertos y su índice agrupado está en algo así como una columna de IDENTIDAD, entonces podría haber problemas de contención para esa parte concreta del disco, ya que todas las filas nuevas se están insertando en el mismo lugar.

Para tablas de búsqueda pequeñas siempre coloco el índice agrupado en PK. Para las tablas de alto impacto, es una buena idea pasar el tiempo pensando (y probando) en varios posibles índices agrupados antes de elegir el mejor.

Answer 7

Recuerde que el índice agrupado es el orden físico en el que se almacena la tabla en el disco.

Por lo tanto, si su índice agrupado se define como ColA, las consultas ColB serán más rápidas cuando realice el pedido en el mismo orden que su índice agrupado. Si SQL tiene que ordenar B, A, requerirá una clasificación posterior a la ejecución para lograr el orden correcto.

Mi sugerencia es agregar un segundo índice no agrupado en B, A. También, dependiendo del tamaño de su columna de datos, INCLUDE (lea la columna incluida) para evitar la necesidad de búsquedas clave. Esto es, por supuesto, siempre que esta tabla no esté muy insertada, ya que siempre debe equilibrar la velocidad de consulta con la velocidad de escritura.

De manera realista, su índice agrupado debe representar el orden en el que es más probable que se acceda a los datos, así como mantener un delicado equilibrio entre insertar/actualizar el costo de IO. Si su índice agrupado es tal que está constantemente insertando en el medio de las páginas, puede sufrir pérdidas de rendimiento allí.

Como han dicho otros, sin conocer la longitud de la mesa, los tamaños de columna, etc. no hay una respuesta correcta. Prueba y error con una gran dosis de pruebas es su mejor opción.

Answer 8

Sólo en caso de que esto no es obvia: el orden de clasificación de su índice deno promete mucho sobre el orden de clasificación de los resultados en una consulta.

En sus consultas, aún debe agregar un

ORDER BY KeyA, KeyB 

o

ORDER BY KeyB, KeyA 

El optimizador puede ser satisfecho de encontrar los datos ya ordenados físicamente en el índice como se desee y ahorrar algo de tiempo, pero cada consulta que se supone que debe entregar datos en un orden particular debe tener una cláusula ORDER BY al final del mismo. Sin un pedido por, SQL Server no hace ninguna promesa con respecto al orden de un conjunto de registros, o incluso que volverá en el mismo orden de consulta a consulta.

Answer 9

Sí, debe sugerir, normalmente el motor de búsqueda intenta averiguar el mejor plan de ejecución y el índice a utilizar, sin embargo, en algún momento es mejor forzar el motor de consulta para usar el índice específico. Hay otras consideraciones al planificar el índice y al utilizar el índice en su consulta. por ejemplo, el ordenamiento de columna en índice, ordenamiento de columna en cláusula where. usted podría referirse siguiente enlace para conocer:

http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/

• Mejores prácticas para utilizar índices
• cómo sacar el máximo de formularios índices de rendimiento
• agrupados Consideraciones índice
• Índices Consideraciones no agrupados

Estoy seguro de que esto lo ayudará a planificar el índice.