¿Cuál es la estrategia de indexación óptima para una tabla de relaciones?

Una tabla de relación es la solución común a la representación de un muchos-a-muchos (m: n) relación.¿Cuál es la estrategia de indexación óptima para una tabla de relaciones?

En la forma más simple, que combina las claves externas que hacen referencia a las dos tablas relativas a una nueva clave principal compuesta:

 
A  AtoB  B 
----  ----  ---- 
*id  *Aid  *id 
data  *Bid  data

cómo debería ser indexados para proporcionar un rendimiento óptimo en cada situación JOIN?

índice agrupado sobre (Aid ASC, Bid ASC) (esto es obligatorio de todos modos, supongo)
opción # 1 más un adicional de índices sobre (Bid ASC, Aid ASC)
o la opción # 1 más un adicional de índices sobre (Bid ASC)
otras opciones? ¿Cosas específicas del vendedor, tal vez?

Fuente

2009-05-12 Tomalak

Niza pregunta, gracias. Haré una publicación en mi blog. – Quassnoi

Mi Google Reader me dirá.:) – Tomalak

¡Ah, entonces tú eres el otro tipo! – Quassnoi

Hice algunas pruebas, y aquí está la actualización :

Para cubrir todos los casos posibles, usted necesita tener:

CLUSTERED INDEX (a, b) 
INDEX (b)

Esto cubrirá todas JOIN sutiations Y ORDER BY

Tenga en cuenta que un índice en B está realmente ordenado en (B, A) ya que hace referencia a filas agrupadas.

Mientras sus a y b tablas tienen PRIMARY KEY 's en las identificaciones, que No necesidad de crear índices adicionales para manejar ORDER BY ASC, DESC.

Ver la entrada en mi blog para más detalles:

Indexing a link table

Fuente

2009-05-12 09:24:17 Quassnoi

Aún necesita un índice en (B DESC) para usar un índice para ORDER BY b, un DESC – Quassnoi

¿Un ÍNDICE (b, a) no tiene un beneficio? – Tomalak

ÍNDICE (b) en realidad es INDICE (b, a, b), ya que su tabla está agrupada. Un índice en (b, a) sería en realidad ÍNDICE (b, a, a, b) que es totalmente inútil. – Quassnoi

Supongo que la solución 2 es óptima. Elegiría el orden del índice agrupado mirando los valores y esperando cuál tiene filas más distintas. Ese es el primero. También es importante tener unique o primary key índices en las tablas principales.

Dependiendo del DBMS, el número 3 podría funcionar tan bien como el número 2. Podría o no ser lo suficientemente inteligente como para considerar los valores (clave del índice agrupado) en el índice no agrupado para otra cosa que no sea referir la fila real. Si puede usarlo, entonces el número 3 sería mejor.

Fuente

2009-05-12 09:24:13

Pero * ¿cuál * es óptimo? 1., 2. o 3.? :) Además, la pregunta es más un procedimiento general que un problema específico. – Tomalak

Tomalak: Pensé que te referías a todos :) Oh, no vi el número 1 + ... Elegiría el número 2. –

Hm, tal vez tenga que volver a formatear la pregunta para que quede más claro. :) – Tomalak

he hecho algunas pruebas rápidas y sucias mediante el examen de los planes de ejecución en el servidor SQL 2005. Los planes mostraron que SQL usa el índice agrupado en Ayuda, oferta para la mayoría de las consultas. La adición de un índice en Oferta (ASC) muestra que se utiliza para las consultas de tipo

select * from A 
    inner join AtoB on Aid = A.id 
    inner join B on Bid = B.id 
where Bid = 1

Así que estoy votando por la solución # 3.

Fuente

2009-05-12 10:01:46 edosoft

Usted anticipó lo que @Quassnoi se tomó el tiempo de rastrear y explicar. +1 en cualquier caso. :) – Tomalak

¿Cuál es la estrategia de indexación óptima para una tabla de relaciones?

Respuesta

Cuestiones relacionadas