2010-06-29 12 views
7

me encontré escribiendo la consulta en formas diferentes personas, como se muestra a continuación tipo Iqué consulta es mejor y más eficaz - mysql

SELECT JS.JobseekerID 
     , JS.FirstName 
     , JS.LastName 
     , JS.Currency 
     , JS.AccountRegDate 
     , JS.LastUpdated 
     , JS.NoticePeriod 
     , JS.Availability 
     , C.CountryName 
     , S.SalaryAmount 
     , DD.DisciplineName 
     , DT.DegreeLevel 
    FROM Jobseekers JS 
INNER 
    JOIN Countries C 
     ON JS.CountryID = C.CountryID 
INNER 
    JOIN SalaryBracket S 
     ON JS.MinSalaryID = S.SalaryID 
INNER 
    JOIN DegreeDisciplines DD 
    ON JS.DegreeDisciplineID = DD.DisciplineID 
INNER 
    JOIN DegreeType DT 
    ON JS.DegreeTypeID = DT.DegreeTypeID 
WHERE 
    JS.ShowCV = 'Yes' 

tipo II

SELECT JS.JobseekerID 
     , JS.FirstName 
     , JS.LastName 
     , JS.Currency 
     , JS.AccountRegDate 
     , JS.LastUpdated 
     , JS.NoticePeriod 
     , JS.Availability 
     , C.CountryName 
     , S.SalaryAmount 
     , DD.DisciplineName 
     , DT.DegreeLevel 
    FROM Jobseekers JS, Countries C, SalaryBracket S, DegreeDisciplines DD 
     , DegreeType DT 
    WHERE 
      JS.CountryID = C.CountryID 
      AND JS.MinSalaryID = S.SalaryID 
      AND JS.DegreeDisciplineID = DD.DisciplineID 
      AND JS.DegreeTypeID = DT.DegreeTypeID 
      AND JS.ShowCV = 'Yes' 

soy utilizando la base de datos Mysql

Ambos funcionan muy bien, pero me pregunto

  1. ¿cuál es la mejor práctica para usar todo el tiempo para cualquier situación?
  2. Rendimiento sabio, ¿cuál es mejor? (Diga la base de datos como millones de registros)
  3. ¿Alguna ventaja de una sobre la otra?
  4. ¿Hay alguna herramienta donde pueda verificar cuál es la mejor consulta?

Gracias de antemano

+0

edición: Scorpi0 menciona bastante bien, asegúrese de echar un vistazo a sus SO-enlaces – DrColossos

+0

nop, el DBMS detectar la unión interna, ya que no realiza una combinación cruzada –

+0

hmm, creo que he leído en alguna parte en los foros de MySQL, pero es posible que tengas razón al respecto. ¡Tal vez pueda encontrar el artículo gracias por señalar! – DrColossos

Respuesta

10

1- Es una obviedad, utilizar el tipo I

2- El tipo II también se una se llaman 'implícito sumo', mientras que el tipo I se llaman 'explícita unirse'. Con el DBMS moderno, no tendrá ningún problema de rendimiento con la consulta normal. Pero creo que con una gran consulta de múltiples combinaciones complejas, el DBMS podría tener problemas con la combinación implícita. El uso de la unión explícita solo podría mejorar su plan de explicación, ¡para obtener un resultado más rápido!

3- Por lo tanto, el rendimiento podría ser un problema, pero quizás lo más importante es que la legibilidad mejora para un mayor mantenimiento. La combinación explícita explica exactamente qué es lo que desea unir en qué campo, mientras que la combinación implícita no aparece si crea una combinación o un filtro. La cláusula Where es para filtro, ¡no para unirse!

Y un gran punto importante para la unión explícita: la combinación externa es realmente molesta con la unión implícita. Es tan difícil de leer cuando quieres una combinación múltiple con la combinación externa que la combinación explícita es LA solución.

4- Plan de ejecución son lo que necesita (See the doc)

Algunos duplicados:

Explicit vs implicit SQL joins

SQL join: where clause vs. on clause

INNER JOIN ON vs WHERE clause

1

en la mayor parte del código que he visto, los querys se hacen como tu tipo II - pero creo Tipo-I es mejor debido a la legibilidad (y más lógica - una unión es una unión, por lo que debe escribirla como una unión (aunque la segunda es solo otro estilo de escritura para combinaciones internas)).

en rendimiento, no debería haber una diferencia (si hay una, creo que Type-I sería un poco más rápido).

1

Mi sugerencia.

Actualice todas sus tablas con cierta cantidad de registros. Acceda a la consola MySQL y ejecute SQL ambos comandos uno por uno. Puede ver el tiempo de ejecución de tiempo en la consola.

1

Para las dos consultas que usted ha mencionado (cada uno con solo combinaciones internas) cualquier consulta de base de datos moderna optimiza r debería producir exactamente el mismo plan de consulta y, por lo tanto, el mismo rendimiento.

Para MySQL, si prefija la consulta con EXPLAIN, escupirá información sobre el plan de consulta (en lugar de ejecutar la consulta). Si la información de ambas consultas es la misma, el plan de consulta es el mismo y el rendimiento será idéntico. Desde el MySQL Reference Manual:

EXPLAIN devuelve una fila de información para cada tabla que se utiliza en el instrucción SELECT. Las tablas se enumeran en la salida en el orden en que MySQL las leería mientras procesaba la consulta . MySQL resuelve todas las combinaciones utilizando un método de combinación de bucle anidado. Esto significa que MySQL lee una fila de la primera tabla , y luego encuentra una fila correspondiente en la segunda tabla, la tercera tabla, y así sucesivamente. Cuando se procesan todas las tablas , MySQL genera las columnas y las pistas seleccionadas a través de la lista de la tabla hasta que se encuentre una tabla para que contenga más filas. La siguiente fila se lee de esta tabla y el proceso continúa con la siguiente tabla .

Cuando se utiliza la palabra clave extendida, EXPLIQUE produce información extra que se puede ver mediante la emisión de una declaración VER ADVERTENCIAS después de la declaración explicar. Esta información muestra cómo el optimizador califica nombres de tablas y columnas en la instrucción SELECT, lo que el SELECT se parece a después de la aplicación de reescritura y reglas de optimización, y posiblemente otras notas sobre el proceso de optimización.

¿En cuanto a qué sintaxis es mejor? Eso depende de usted, pero una vez que se mueve más allá de las uniones internas a las combinaciones externas, deberá usar la sintaxis más nueva, ya que no existe un estándar para describir las uniones externas utilizando la sintaxis de unión implícita más antigua.

Cuestiones relacionadas