Acelerando las uniones internas entre una mesa grande y una mesa pequeña

Question

Esto puede ser una pregunta tonta, pero puede arrojar algo de luz sobre cómo las uniones funcionan internamente.

Digamos que tengo una tabla grande L y una pequeña tabla S (100K filas vs. 100 filas).

Habría alguna diferencia en términos de velocidad entre las dos opciones siguientes ?:

OPTION 1:     OPTION 2: 
---------     --------- 
SELECT *     SELECT * 
FROM L INNER JOIN S  FROM S INNER JOIN L 
ON L.id = S.id;   ON L.id = S.id; 

en cuenta que la única diferencia es el orden en el que se unen las tablas.

Me doy cuenta de que el rendimiento puede variar entre los diferentes lenguajes SQL. Si es así, ¿cómo se compararía MySQL con Access?

Answer 1

No, el orden no importa.

Casi todos los RDBMS (tales como MS Access, MySQL, SQL Server, ORACLE, etc.) utilizan un optimizador basado en costos basado en estadísticas de columna. En la mayoría de las situaciones, el optimizador elegirá un plan correcto. En el ejemplo que proporcionó, el orden no importará (siempre que las estadísticas estén actualizadas).

para decidir qué estrategia de consultas utilizar, el optimizador de motor Jet utiliza estadísticas. Los siguientes factores son algunos de los factores que estos estadísticas se basan en:

• El número de registros en una tabla
• El número de páginas de datos en una tabla
• La ubicación de la tabla
• índices Tanto si están presentes
• Cómo única los índices son

Nota: No puede ver los esquemas de optimización del motor de la base de datos Jet, y no puede especificar cómo optimizar una consulta . Sin embargo, puede usar el Documentador de base de datos para determinar si hay índices presentes y cómo es un índice único.

Sobre la base de estas estadísticas, el optimizador de continuación, selecciona la mejor estrategia de consulta interna para tratar con una consulta en particular.

Las estadísticas se actualizan cada vez que se compila una consulta . Una consulta se marca para compilar al guardar cualquier cambio en la consulta (o en sus tablas subyacentes ) y cuando se compacta la base de datos . Si una consulta es marcada para la compilación, la compilación de y la actualización de las estadísticas se produce la próxima vez que se ejecute la consulta. La compilación generalmente toma de uno segundos a cuatro segundos.

Si añade un número significativo de registros a su base de datos, debe abierta y luego guardar las consultas a recompilar las consultas. Por ejemplo, si diseña y luego prueba una consulta por usando un pequeño conjunto de datos de muestra, debe volver a compilar la consulta después de que se agreguen registros adicionales a la base de datos . Al hacer esto, desea para asegurarse de que se obtenga el rendimiento óptimo de consulta cuando su aplicación esté en uso.

Ref.

pueden ser de interés: ACC: How to Optimize Queries in Microsoft Access 2.0, Microsoft Access 95, and Microsoft Access 97

de Tony Toews Microsoft Access Performance FAQ vale la pena leer.

Answer 2

Sé que Oracle no está en su lista, pero creo que las bases de datos más modernas se comportarán de esa manera.

Puede ver en el siguiente plan de ejecución, que no hay diferencia entre las dos instrucciones.

Es un acceso completo a cada una de las dos tablas (sin índice en mi caso), y luego a HASH JOIN. Como quiere que todo de ambas tablas, ambas tablas necesitan ser leídas y unidas, la secuencia no tiene impacto.

--------------------------------------------------------------------------- 
| Id | Operation   | Name | Rows | Bytes | Cost (%CPU)| Time  | 
--------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |  | 100 | 700 | 42 (12)| 00:00:01 | 
|* 1 | HASH JOIN   |  | 100 | 700 | 42 (12)| 00:00:01 | 
| 2 | TABLE ACCESS FULL| S | 100 | 300 |  2 (0)| 00:00:01 | 
| 3 | TABLE ACCESS FULL| L | 100K| 390K| 38 (8)| 00:00:01 | 
---------------------------------------------------------------------------