J'ai besoin de trouver tous les enregistrements créés dans une année donnée à partir d'une base de données MySQL. Y a-t-il une façon que l'un des éléments suivants serait plus lent que l'autre? ou P> WHERE YEAR(create_date) = '2009'
4 Réponses :
Ceci: ... fonctionne mieux car il ne modifie pas les données de la colonne index ne peut pas être utilisé sur Create_Date . Cela signifie que s'il y a un index sur le create_date , l'index peut être utilisé - car l'index est sur la valeur réelle telle qu'elle existe dans la colonne. année (create_date) , car il s'agit uniquement d'une partie de la valeur (qui nécessite une extraction).
Chaque fois que vous utilisez une fonction sur une colonne, il doit effectuer la fonction de chaque ligne afin de voir si elle correspond à la constante. Cela empêche l'utilisation d'un index.
La règle de base du pouce est donc d'éviter d'utiliser des fonctions sur le côté gauche de la comparaison.
Sargable signifie que le SGBD peut utiliser un index. Utilisez une colonne sur le côté gauche et une constante du côté droit pour permettre à la SGBM d'utiliser un index.
Même si vous n'avez pas d'index sur la colonne Create_Date, il existe toujours des frais généraux sur le SGBD pour exécuter la fonction d'année () pour chaque ligne. Donc, peu importe quoi, la première méthode est très probablement plus rapide.
Idées:
Mais je m'attendrais à gagner. À moins que l'optimisateur ne soit assez intelligent pour effectuer l'optimisation pour l'année (), dans ce cas serait la même.
Une autre idée:
Je ne pense pas que vous vous souciez.
Si vous n'avez que quelques enregistrements par an, la requête serait rapide même si elle effectuait une numérisation de table complète, car même avec (dis) des données de 100 ans, il y a si peu d'enregistrements.
Si vous avez un très grand nombre d'enregistrements par an (par exemple 10 ^ 8), la requête serait très lente dans tous les cas, car de retour que de nombreux dossiers prennent beaucoup de temps.
Vous n'avez pas dit combien de données d'années que vous conservez. Je suppose que si c'est une base de données archéologique, vous pourriez avoir quelques milliers, auquel cas vous vous souciez peut-être si vous avez une charge massive de données.
Je trouve qu'il est extrêmement improbable que votre demande remarque réellement la différence entre un "bon" plan d'explication (à l'aide d'une analyse de la plage d'index) et d'un plan d'explication "mauvais" (analyse de la table complète) dans ce cas.