sql - uso - ¿Cómo funcionan los índices compuestos?
indices tabla sql server (5)
El índice compuesto es como un índice de alfabeto simple en un diccionario, pero abarca dos o más letras, como esta:
AA - page 1
AB - page 12
etc.
Las filas de la tabla se ordenan primero por la primera columna en el índice, luego por la segunda, etc.
Se puede usar cuando busca por ambas columnas O por la primera columna. Si su índice es así:
AA - page 1
AB - page 12
…
AZ - page 245
BA - page 246
…
puede usarlo para buscar en 2 letras ( = 2 columnas en una tabla), o como un índice simple en una letra:
A - page 1
B - page 246
…
Tenga en cuenta que en el caso de un diccionario, las páginas mismas están ordenadas alfabéticamente. Ese es un ejemplo de un índice CLUSTERED .
En un índice simple, no CLUSTERED , las referencias a las páginas están ordenadas, como en un libro de historia:
Gaul, Alesia: pages 12, 56, 78
Gaul, Augustodonum Aeduorum: page 145
…
Gaul, Vellaunodunum: page 24
Egypt, Alexandria: pages 56, 194, 213, 234, 267
Los índices compuestos también se pueden usar cuando ORDER BY dos o más columnas. En este caso, una cláusula DESC puede ser útil.
Vea este artículo en mi blog sobre el uso de la cláusula DESC en un índice compuesto:
He creado índices compuestos ( índices para ti gente matemática) en tablas antes, con una suposición de cómo funcionaban. Solo tenía curiosidad si mi suposición es correcta o no.
Supongo que cuando enumera el orden de las columnas para el índice, también está especificando cómo se agruparán los índices. Por ejemplo, si tiene las columnas a , b y c , y especifica el índice en el mismo orden a ASC , b ASC y c ASC entonces el índice resultante será esencialmente muchos índices para cada "grupo" en a .
¿Es esto correcto? Si no, ¿cómo se verá realmente el índice resultante?
La implementación más común de los índices usa B-trees para permitir búsquedas algo rápidas, y también exploraciones de rango razonablemente rápidas. Es demasiado para explicarlo aquí, pero aquí está el artículo de Wikipedia sobre B-trees . Y tiene razón, la primera columna que declara en el índice de creación será la columna de orden superior en el árbol B resultante.
Una búsqueda en la columna de orden superior equivale a un análisis de rango, y un índice de árbol B puede ser muy útil para dicha búsqueda. La forma más fácil de ver esto es por analogía con los catálogos de tarjetas antiguas que tiene en bibliotecas que aún no se han convertido a catálogos en línea.
Si busca todas las tarjetas para los Autores cuyo apellido es "Clemens", simplemente vaya al catálogo del autor, y muy rápidamente encuentre un cajón que diga "CLE-CLI" en el frente. Ese es el cajón correcto. Ahora haces una especie de búsqueda binaria informal en ese cajón para encontrar rápidamente todas las cartas que dicen "Clemens, Roger" o "Clemens, Samuel" en ellas.
Pero supongamos que quiere encontrar todas las tarjetas para los autores cuyo primer nombre es "Samuel". Ahora estás en el arroyo, porque esas cartas no están reunidas en un solo lugar en el catálogo de Autor. Un fenómeno similar ocurre con los índices compuestos en una base de datos.
Diferentes DBMS difieren en cuán inteligente es su optimizador para detectar escaneos de rango de índice y estimar con precisión su costo. Y no todos los índices son B-trees. Tendrás que leer los documentos de tu DBMS específico para obtener la información real.
Los índices compuestos funcionan igual que los índices regulares, excepto que tienen claves de valores múltiples.
Si define un índice en los campos (a, b, c), los registros se ordenan primero en a, luego b, luego c.
Ejemplo:
| A | B | C |
-------------
| 1 | 2 | 3 |
| 1 | 4 | 2 |
| 1 | 4 | 4 |
| 2 | 3 | 5 |
| 2 | 4 | 4 |
| 2 | 4 | 5 |
No. El índice resultante será un índice único pero con la clave compuesta.
KeyX = A, B, C, D; KeyY = 1,2,3,4;
Index KeyX, KeyY será en realidad: A1, A2, A3, B1, B3, C3, C4, D2
De modo que en caso de que necesite encontrar algo mediante KeyX y KeyY, será rápido y usará un índice único. Algo así como SELECT ... WHERE KeyX = "B" AND KeyY = 3.
Pero es importante entender: WHERE KeyX =? las solicitudes usarán ese índice, mientras que WHERE KeyY =? NO usará tal índice en absoluto.
Según entiendo, los índices compuestos funcionan igual que los índices regulares, excepto que tienen claves de valores múltiples. Si define un índice en los campos (a, b, c), dado que el índice compuesto se almacenará en un BinaryTree, su índice funcionará solo siguiendo combinaciones de búsquedas.
ABC
AB
A
Por ejemplo, crear un índice compuesto para los campos a, byc equivale a crear índices separados para a, ab y abc.