Signification de "Sélectionner les tables optimisées" dans MySQL Expliquer le plan
Quelle est la signification de Select tables optimized away dans le plan Explain de MySQL?
explain select count(comment_count) from wp_posts;
+----+-------------+---------------------------+-----------------------------+
| id | select_type | table,type,possible_keys, | Extra |
| | | key,key_len,ref,rows | |
+----+-------------+---------------------------+-----------------------------+
| 1 | SIMPLE | all NULLs | Select tables optimized away|
+----+-------------+---------------------------+-----------------------------+
1 row in set (0.00 sec)
Remarque: La sortie de explain plan a été modifiée pour la lisibilité.
Cela signifie que vous avez effectué une requête qui ne fait que compter le nombre de lignes dans une table, et cette table est une table MyISAM. Les tables MyISAM sont stockées avec un nombre de lignes distinct. Par conséquent, pour effectuer cette requête, MySQL n'a pas besoin d'examiner les données de lignes de la table. Au lieu de cela, il renvoie immédiatement le nombre de lignes pré-calculé. Par conséquent, l’accès à la table est optimisé et la requête est ultra-rapide.
La même chose ne se produira pas sur d'autres moteurs de stockage dans MySQL tels que InnoDB. Mais en réalité, vous voulez utiliser InnoDB et non MyISAM dans la plupart des cas pour diverses autres raisons. (Et même sans l'optimisation du nombre de lignes, ce type de requête est très, très rapide.)
select count(comment_count) from wp_posts;
Est-ce ce que vous vouliez vraiment faire? C'est la même chose que SELECT COUNT(*)... (en supposant que comment_count ne peut pas être NULL, ce qui n'est pas le cas ou vous n'auriez pas eu l'optimisation). Si vous voulez un total de comment_counts, vous devriez utiliser SUM(comment_count) et vous n’obtiendrez pas le comportement «optimisé».
De la documentation MySQL:
La requête ne contenait que des fonctions d'agrégat (MIN (), MAX ()) qui ont toutes été résolues à l'aide d'un index, ou COUNT (*) pour MyISAM, sans aucune clause GROUP BY. L'optimiseur a déterminé qu'une seule ligne devait être renvoyée.
En gros, cela signifie que votre requête utilise des données directement disponibles pour MySQL et qu'elle s'exécutera à temps constant.
Cela signifie que la table est complètement optimisée en dehors de la requête. Vous ne pouvez pas faire mieux que ça.
La réponse acceptée et la réponse la plus votée semblent suggérer que ce type d'explication ne s'applique qu'aux tables MyISAM. Mais je vois cela avec une table InnoDB.
J'ai consulté la documentation de MySQL ici pour la version 5.6, https://dev.mysql.com/doc/refman/5.6/fr/explain-output.html#explain_extra
Je ne vois pas que l'explication se limite à MyISAM. Mais dans le cas spécifique de COUNT (*), une note indique que ce type d'explication deviendra valide si la table est MyISAM.
'Pour les moteurs de stockage qui conservent un nombre exact de lignes par table (tel que MyISAM, mais pas InnoDB), cette valeur supplémentaire peut survenir pour les requêtes COUNT (*) pour lesquelles la clause WHERE est manquante ou toujours vraie et il n'y a pas de clause GROUP BY. . (Il s'agit d'une instance d'une requête groupée implicitement dans laquelle le moteur de stockage détermine si un nombre déterministe de lignes peut être lu.) '
Pour les tables innodb, j'ai vu l'option "Sélectionner les tables optimisées" lors de la recherche du minimum ou du maximum d'une colonne contenant auto_increment. Le fichier information_schema.tables conserve le maximum d'auto_incrément afin que l'optimiseur puisse simplement y regarder et ne jamais toucher à la table user. Cela ne fonctionnera pas pour des tâches telles que count, car il pourrait y avoir des lacunes, de sorte que l'optimiseur doit accéder à la table des utilisateurs pour obtenir la réponse.
Difficile à dire sans voir votre requête, mais ce serait la conséquence si vous sélectionniez par exemple une valeur constante -
SELECT 1 DE atable
ou un ou plusieurs de vos tableaux n'est pas nécessaire pour répondre à la question.