2010-10-20 15 views
7

me encontré con este párrafo en la documentación de Oracleorden de las tablas de consulta de unión

si desea seleccionar el nombre de cada departamento junto con el nombre de su director , se puede escribir la consulta en uno de dos maneras. En el primer ejemplo que sigue, la indirecta/++ ordenó ++/ dice que hacer la unión en el orden de los tablas aparecen en la cláusula FROM con intentar optimizar el orden de combinación.

SELECT /*+ordered*/ d.NAME, e.NAME 
FROM DEPT d, EMP e WHERE d.MGR = e.SS# 

o:

SELECT /*+ordered*/ d.NAME, e.NAME 
FROM EMP e, DEPT d WHERE d.MGR = e.SS# 

Supongamos que hay 10 departamentos y 1000 empleados, y que el tabla interna en cada consulta tiene un índice en la columna unirse. En la primera consulta, , la primera tabla produce 10 filas calificadas (en este caso, toda la tabla). En la segunda consulta, la primera tabla produce 1000 filas calificadas. La primera consulta accederá a la tabla EMP 10 veces y escaneará la tabla DEPT una vez. La segunda consulta escaneará la tabla EMP una vez, pero accederá a la tabla DEPT 1000 veces. Por lo tanto, la primera consulta funcionará mucho mejor. Como norma general , las tablas deben ser organizadas a partir de las filas numéricas más efectivas hasta el mayor número efectivo de filas . El tamaño de fila efectivo de una tabla en una consulta se obtiene por aplicando las condiciones lógicas que se resuelven por completo en esa tabla.

Pero no entiendo esto correctamente. Si hay filas m en las filas de la tabla t1 y n en la tabla t2, ¿el motor sql no pasaría por las filas m x n en ambos casos?

Actualización: Gracias por todas las respuestas. No anularé el optimizador, solo quería confirmar mi pensamiento.

+2

¿Puede usted por favor enviar un enlace al documento en el que lee esto? –

+0

Falta la cláusula 'WHERE' en su segunda consulta, que se encuentra en la documentación de Oracle. –

+0

@Peter - Se agregó donde la cláusula :) – Jerry

Respuesta

2

Eso depende de la instrucción WHERE.

SELECT /++ordered++/ d.NAME, e.NAME FROM DEPT d, EMP e WHERE d.MGR = e.SS# 

Seleccionará todos los gerentes para cada departamento. Como hay 10 departamentos, esto da como resultado la obtención de 10 registros.

SELECT /++ordered++/ d.NAME, e.NAME FROM EMP e, DEPT d 

Esto seleccionará todos los empleados con el nombre del departamento que están trabajando. Como hay 1000 empleados, el conjunto de resultados se tiene 1000 filas.

una unión no hará que su motor para recorrer m x n filas, estás de resultados de una combinación interna será siempre m si m < n

+0

No entiendo lo que quiere decir con "resultado de una unión interna siempre será m x m si m

+0

¿Es esto cierto incluso si no hay índice en las claves de unión? (De nuevo, esto es solo por conocimiento. Entiendo que las uniones en no índices no son recomendables.) – Jerry

+0

@Tony, depende de su cláusula WHERE/ON. En el primer caso, el conjunto de resultados contendrá 10 filas, en el segundo 1000. @Jerry ¿Qué quiere decir con índice en las teclas de unión? – thomaux

4

Pues bien, en el primer caso el número de lecturas lógicas es 10 + 10 , en el segundo 1000 + 1000, con cada departamento leído en promedio 100 veces.

Sin embargo, escribir consultas con el PEDIDO así pegado no es una práctica normal. Lo mejor es dejar la optimización al optimizador la mayor parte del tiempo.

No estoy seguro exactamente de qué documentación obtuviste esa cita, pero donde la he visto va precedida por este párrafo tan importante que has omitido. Cito aquí para el beneficio de otros que de lo contrario puede pensar que este método de escribir consultas es estándar:

Normalmente optimizador elige el mejor plan de ejecución , un orden óptimo de tablas a unir. En caso de que el optimizador no esté produciendo un buen plan de ejecución , puede controlar el orden de ejecución utilizando el SQL de característica HINTS . Para obtener más información, consulte Oracle Database Lite SQL Referencia.

- Oracle® Database Lite Developer's Guide

+2

+1, aunque creo que asume que NESTED LOOP JOIN (una HASH JOIN probablemente se elija si no hay condición de filtro). El hecho de que el documento asume una unión de bucle anidado (¿RULE optimizer?) Y recomienda el uso de pistas me hace pensar que este consejo proviene de un documento muy antiguo (Oracle 7?). De todos modos, un buen consejo para dejar que el optimizador haga su trabajo. –

1

Realmente encontró que en documentos de Oracle?

No debe utilizar la sugerencia ORDERED y dejar que el oráculo tome la decisión por usted, que la mayoría de las veces funciona muy bien hoy en día.

Sin embargo, el orden de unión hace una diferencia en cuanto al rendimiento.

El ejemplo parece discutir los de bucles anidados:

Case 1: 
-> 1 lookup to find 10 rows in table A 
-> 10 index lookups in table B 

Case 2: 
-> 1 lookup to find 1000 rows in table B 
-> 1000 index lookups in table A 
Cuestiones relacionadas