Vamos a echar un vistazo a la información que nos da el propio MySQL acerca de las consultas que generamos en el anterior post (es conveniente leerlo para una mejor comprensión, aunque no imprescindible). Esto lo llevamos a cabo gracias a la sentencia EXPLAIN. Su uso es tan simple como poner esa cadena (EXPLAIN) justo al principio de cualquier consulta, y ejecutarla. En lugar de ejecutar la sentencia y mostrarnos los resultados, la salida nos dará una información bastante aproximada de cómo MySQL va a tratar y a ejecutar una sentencia SELECT dada. Con esto, la tarea de optimización de consultas se facilita, pudiendo ver si necesitamos crear algún índice para aligerar cierto tipo de SELECTS, si no se está usando un índice que creíamos que si, si estamos haciendo las relaciones entre tablas de un modo correcto, etc... Antes de ponerlo a prueba con los queries del anterior post, hagamos una breve descripción de lo que MySQL nos va a mostrar:
Y ahora los queries con EXPLAIN explicados (válgase la rebuznancia): Test time (y Test time 2, puesto que la salida de EXPLAIN es la misma)
Aquí tenemos un SELECT simple (sin unions ni subselects) sobre la tabla vehiculo que buscará sobre todas las entradas. Efectivamente, en la tabla vehiculo solo hay 10 filas, y no se usará ningún índice porque el campo 'clase' no dispone de ningún tipo de indexación. EXPLAIN SELECT id_cliente FROM clientes_vehiculo WHERE id_vehiculo = el_anterior_id_obtenido;
Estamos en el mismo caso de antes, sólo que esta vez la tabla clientes_vehiculo tiene 11 entradas. EXPLAIN SELECT nombre FROM clientes WHERE id = el_anterior_id_obtenido;
Esta vez encontramos que el tipo de join/relación es const, que significa que como mucho la tabla tiene una sola coincidencia con una fila. Se da porque comparamos una constante con la PK de la tabla. Esto se traduce en que la query será resuelta con gran rapidez. Vemos también que la PK consta como posible índice a usar, cosa que acaba pasando. Finalmente confirmamos la causa de la rapidez; MySQL ve que sólo es necesario analizar una fila (de las aprox. 5000 que tiene la tabla!) para ejecutar la query.
Lo interesante y a la vez aterrador de este query es que el primer SELECT tiene que recorrer todas las filas de su tabla (clientes). El primer SELECT depende del segundo (DEPENDENT SUBQUERY), y asimismo también debe recorrer todas las filas de su tabla (clientes_vehiculo). Finalmente, el segundo SELECT también depende del tercero (DEPENDENT SUBQUERY), aunque esta vez tenemos un interesante UNIQUE SUBQUERY, es decir, un reemplazo del subquery por el índice para un mejor desempeño.
¡Oh! ¿Qué pasó aquí? Para MySQL tenemos 3 SELECTS simples, como en el primer caso, con la diferencia de que ahora iteraremos a través de menos filas (13 en lugar de 22)... ¡Fantástico! En realidad sólo iteramos entera la tabla clientes_vehiculo (cv). Para las 2 últimos SELECTS vemos que el tipo de relación es eq_ref: se da cuando el índice es usado para la relación/join y además es PK o UNIQUE. EXPLAIN SELECT c.nombre FROM clientes c, clientes_vehiculo cv, vehiculo v WHERE c.id = cv.id_cliente AND cv.id_vehiculo = v.id AND v.clase = 'motocicleta';Para esta segunda query no hace falta poner la tabla resultante, puesto que es igual que la anterior. En este caso, el cambio de orden de los factores no altera el producto. Comentarios (5) |