una - nomenclatura indices sql server
Índice agrupado de SQL Server-Pregunta del índice de orden (9)
Tengo una mesa como esa:
keyA keyB data
keyA y keyB juntos son únicos, son la clave principal de mi tabla y componen un índice agrupado.
Hay 5 valores posibles de keyB pero un número ilimitado de valores posibles de keyA ,. keyB generalmente se incrementa.
Por ejemplo, los siguientes datos se pueden ordenar de 2 maneras dependiendo de qué columna de clave se solicita primero:
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
¿Tengo que decirle al índice agrupado cuál de las columnas clave tiene menos valores posibles para permitirle ordenar primero los datos por ese valor? ¿O no importa en términos de rendimiento que se ordena primero?
Sí, debe sugerir que, normalmente, el motor de búsqueda intente descubrir el mejor plan de ejecución y el índice a utilizar, sin embargo, en algún momento es mejor forzar al motor de consultas a 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. puede consultar el siguiente enlace para saber sobre:
http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/
- Mejores prácticas para usar índices
- Cómo obtener mejores índices de forma de rendimiento
- Consideraciones sobre índices agrupados
- Consideraciones sobre índices no agrupados
Estoy seguro de que esto lo ayudará a planificar el índice.
Como han dicho otros, el orden se basa en cómo lo especifique en el script de creación de í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 mediante el uso de 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 las inserciones más que 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 las 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.
Creo que SQL Server lo ordena exactamente de la manera que usted lo dice. 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 quieres 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.
En caso de que esto no sea obvio: el orden de clasificación de su índice no 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 estar contento de encontrar los datos ya ordenados físicamente en el índice como 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 de la misma. 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.
Especifique las columnas en el orden en el que normalmente desea ordenarlas en informes y consultas.
Sin embargo, me daría miedo 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.
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 before keyA en el orden de la columna de índice sería mejor
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.
Recuerde que el índice agrupado es el orden físico en el que se almacena la tabla en el disco.
Entonces, si su índice agrupado se define como ColA, las consultas ColB serán más rápidas cuando se ordenen 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 forma 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.
Si crea un índice (sin agrupar o no) con (claveA, tecla B), así es como se ordenarán los valores, por ejemplo, la primera claveA, luego la tecla B (este es el segundo caso en su pregunta). Si lo quiere al revés, necesita especificar (keyB, keyA).
Puede 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.