Ejecuto la siguiente consulta en mi base de datos:
SELECT e.id_dernier_fichier
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant
Y la consulta funciona bien. Si modifico la consulta de esta manera:
SELECT e.codega
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant
¡La consulta se vuelve muy lenta! El problema es que quiero seleccionar muchas columnas en las tablas eyf, ¡y la consulta puede tomar hasta 1 minuto! Intenté diferentes modificaciones pero nada funciona. Tengo índices en id_ * también en e.codega. Enfants tiene 9000 líneas y FichiersEnfants tiene 20000 líneas. Alguna sugerencia ?
Aquí está la información solicitada (perdón por no haberlas mostrado desde el principio):
Respuestas
2 para la respuesta № 1La diferencia en el rendimiento es posiblemente debido a e.id_dernier_fichier estar en el índice utilizado para JOIN, pero e.codega no estar en ese índice.
Sin una definición completa de ambas tablas y todos sus índices, no es posible saberlo con certeza. Además, incluir los dos PLANES DE EXPLICACIÓN para las dos consultas ayudaría.
Por ahora, sin embargo, puedo elaborar un par de cosas ...
Si se agrupa un ÍNDICE (esto también se aplica a las CLAVES PRIMARIAS), los datos se almacenan físicamente en el orden del ÍNDICE. Esto significa que saber que quieres posición x en el ÍNDICE también implicidad significa que quieres posición x en la mesa.
Sin embargo, si el ÍNDICE no está agrupado, el ÍNDICE solo lo está buscando. Diciendo efectivamente posición x en el ÍNDICE corresponde a posición y en la mesa.
La importancia aquí es cuando se accede a campos noespecificado en el ÍNDICE. Hacerlo significa que debes ir a la TABLA para obtener los datos. En el caso de un ÍNDICE AGRUPADO, usted ya está allí, la sobrecarga de encontrar ese campo es bastante baja. Sin embargo, si el ÍNDICE no está agrupado, tendrá que UNIRSE A LA TABLA al ÍNDICE, luego encontrará el campo Estás interesado en
Nota; Tener un índice compuesto en (id_dernier_fichier, codega) es muy diferente de tener un índice solo (id_dernier_fichier) y un índice separado en solo (codega).
En el caso de su consulta, no creo que necesite cambiar el código en absoluto. Pero usted mayo beneficiarse de cambiar los índices.
Mencionas que quieres acceder muchos campos. Poner todos esos campos en un índice compuesto probablemente no sea la mejor solución. En su lugar, es posible que desee crear un ÍNDICE CLUSTERADO en (id_dernier_fichier). Esto significará que una vez que se haya localizado el * id_dernier_fichier *, ya estará en el lugar correcto para obtener todos los demás campos.
EDITAR Nota sobre MySQL e ÍNDICES EN CLUSTER
13.2.10.1. Índices agrupados y secundarios
Cada tabla de InnoDB tiene un índice especial llamado índice agrupado donde se almacenan los datos de las filas:
- Si define una CLAVE PRIMARIA en su tabla, InnoDB la usa como índice agrupado.
- Si no define una CLAVE PRIMARIA para su tabla, MySQL elige el primer índice ÚNICO que solo tiene columnas NO NULAS como clave principal e InnoDB lo usa como índice agrupado.
- Si la tabla no tiene CLAVE PRIMARIA o adecuadaÍndice ÚNICO, InnoDB genera internamente un índice agrupado oculto en una columna sintética que contiene valores de ID de fila. Las filas están ordenadas por la ID que InnoDB asigna a las filas de dicha tabla. La ID de fila es un campo de 6 bytes que aumenta de forma monotónica a medida que se insertan nuevas filas. Por lo tanto, las filas ordenadas por la ID de fila están físicamente en orden de inserción.