¿Deben unirse a las tablas normalmente se crean como tablas organizadas por índice (índices agrupados)?

Question

Hablando en general ... deberían unir tablas (es decir, tablas asociativas) para crear tablas organizativas de índices (Oracle), índices agrupados (SQL Server) ... o tablas antiguas simples de montón (con índices separados en las 2 columnas).

mi modo de ver si, las ventajas son:

mejora velocidad. Está evitando una vista de tabla de pila.

Mejoramiento del espacio. Está eliminando la tabla de acumulación por completo, por lo que probablemente esté ahorrando ~ 30% de espacio.

Las desventajas:

Índice de Exploración con salto (sólo se aplica a Oracle) .. será más rápido que una mesa de estudio completo, pero más lento que un recorrido de índice. Por lo tanto, las búsquedas en la segunda columna de la clave compuesta serán un poco más lentas (Oracle), mucho más lentas (MSSQL).

Una exploración de índice completa será más lenta que una exploración de tabla completa, de modo que si la mayoría de las veces el optimizador basado en costes realiza uniones Hash (que no aprovechan los índices) ... podría esperar un peor rendimiento. (Suponiendo que el RDBMS no filtra primero las tablas).

Lo que me hace cuestionar si realmente se requieren índices de cualquier tipo para Unirse a tablas, si es que predominará el uso de uniones hash.

Answer 1

Mi regla empírica personal es crear entidades asociativas de dos tablas como index-organized-tables, con la restricción de clave primaria siendo la "dirección" de acceso que espero que se use más comúnmente. En general, agregaré un índice único para cubrir el orden inverso de las claves, por lo que en todos los casos el optimizador debería poder utilizar el escaneo único o el acceso de escaneo de rango.

Las entidades asociativas de tres tablas (o más) generalmente requieren un análisis significativamente mayor.

Además, el optimizador utilizará índices con operaciones de combinación de hash; exploraciones completas en general rápidas, pero índices, no obstante.

Answer 2

Solo me gustaría enumerar y hablar sobre algunas posibles soluciones, que con suerte lo ayudarán a decidir. Una "tabla de unión" contiene dos o tres columnas. Una clave externa a la tabla de la izquierda, digamos a, y una clave externa a la tabla de la derecha, digamos b. La columna opcional es la identidad de fila para la "tabla de unión", digamos id.

Solución 1: Columnas a,b. Sin índice agrupado (un montón), índices en (a,b) y (b,a)
Ambas columnas se almacenan en tres lugares. Es compatible con búsquedas tanto en a y b, y la búsqueda de b no requiere una búsqueda de marcador, ya que a parte del índice (b,a). Buena elección, pero el triple almacenamiento parece un desperdicio. El montón no tiene uso pero debe mantenerse durante las consultas insert y update.

Solución 2: Columnas a, b. Índice agrupado en (a,b), índice en (b,a)
Todos los datos se almacenan dos veces. Puede servir busca en a y b sin una búsqueda de marcador. Este sería el enfoque de mejores prácticas. Cambia el almacenamiento en disco por velocidad.

Solución 3: Columnas a, b. Índice agrupado en (a,b)
Todos los datos se almacenan solo una vez. Puede servir para una búsqueda en a, pero no en b. Pasar de la derecha a la tabla izquierda requerirá un escaneo de tabla. Esto intercambia velocidad por espacio en disco. (Su pregunta menciona la combinación hash. Una combinación hash siempre realiza un escaneo completo.)

Solución 4: Columnas id, a, b.Índice agrupado (id), índice en (a) y (b)
Busca en a o b ambos requieren una búsqueda de marcador. Ambos a y b se almacenan dos veces en el disco, una vez en su propio índice y una vez en la clave agrupada. Esta es la peor solución que podría pensar.

Esta lista no es de ninguna manera exhaustiva. La solución 2 sería una buena opción predeterminada. Yo iría por eso a menos que otra solución demostró ser significativamente mejor en las pruebas.

Answer 3

No estoy familiarizado con la terminología de Oracle, pero para SQL Server la pregunta está redactada de una manera que es confusa. Para aclarar:

• un índice agrupado determina el orden físico de la tabla
• Un índice no agrupado es básicamente una copia de la tabla principal, ordenado por las teclas asignadas
• Puede asignar ("incluir") columnas adicionales en el índice no agrupado, que pueden permitir que el optimizador de consultas utilice esas columnas para satisfacer las consultas, en lugar de hacer una búsqueda de marcador.
• Un montón es una tabla sin un índice de ningún tipo. Todas las consultas en un montón requieren un escaneo.
• Una exploración de índice completa no agrupada es más rápida que una exploración de tabla completa, siempre que el índice sea más estrecho que la tabla y que no necesite búsquedas en marcadores.

Por lo tanto, teniendo esto en cuenta, las claves utilizadas para las uniones generalmente deben tener un índice agrupado o no agrupado asociado, para evitar escaneos de tabla. Puede incluir columnas adicionales en sus índices no agrupados según sea necesario, y prefiere índices agrupados para consultas que cubren un rango contiguo de valores clave con acceso a muchas columnas por fila.