Les deux requêtes suivantes seront-elles exécutées de la même manière?
et
De toute façon, ils devraient afficher les mêmes résultats, alors j'étais curieux si la commande La raison pour laquelle je demande est parce que j'affiche une table pages paginée où j'aurai 20 enregistrements à la fois de la base de données, puis effectuer une deuxième requête qui compte le nombre total d'enregistrements. Je veux savoir si je devrais utiliser les mêmes critères que la première requête utilisée ou si je devais retirer tout le tri des critères? Sélectionnez Count (*) de la commande de la personne par last_name;
Sélectionnez Count (*) de la personne;
par est simplement ignorée.
3 Réponses :
Bien sûr que non. Sauf si le nom de famille est la clé principale et que vous en êtes déjà commandé.
Je ne pense pas que la réponse soit évidente. Oracle jettera souvent des étapes inutiles, un tri particulièrement inutile. J'attendais initialement que les deux requêtes fonctionnent de la même manière.
Ce n'est peut-être pas évident pour vous, mais semble que c'est aussi ce que la réponse correcte est aussi.
L'optimiseur Oracle Requête effectue réellement une sorte (j'ai vérifié cela en regardant le plan d'explication) pour la première version, mais puisque les deux requêtes ne renvoient qu'une ligne, la différence de performance sera très petite.
La réponse de Mike est correcte. La différence de performance peut éventuellement être significative.
ordre de tri par est le tri, Trier agrégé n'est pas vraiment triant. Et bien que les requêtes renvoient le même nombre de lignes, la différence de performance pourrait toujours être énorme.
Selon le plan d'exécution, les deux requêtes sont différentes. Par exemple, la requête: me donnera: p> Comme vous pouvez le constater, nous avons frappé user_pk qui est la clé principale de cette table. p> Si je trie par une colonne non indexée: p> Je vais obtenir: p> INDEX (FAST FULL SCAN) 3.0 3 453812 3457 13828 1 TPMDBO USER_PK FAST FULL SCAN INDEX (UNIQUE) ANALYZED
Avez-vous vérifié le plan de requête en premier? Je suis sûr que vous avez l'analyseur si vous vous souciez de telles différences. Il vous dira si le trier se produit ou non.
Je supprimerais une clause de commande de toutes les fonctions d'agrégat commutatives (telles que le nombre ou la somme) simplement parce que c'est inutile.
Les résultats peuvent différer dans différentes versions d'Oracle. Supprimer la commande par une requête qui ne renvoie qu'un agrégat est une optimisation optionnelle.
@JEFFREYKEMP Merci. Pour moi, les résultats avaient été différents lorsque j'ai utilisé expliquer le plan. Je suis maintenant curieux pourquoi il ne serait pas toujours optimisé?
Aucune optimisation n'est automatique - elle nécessite un code pour mettre en œuvre. Oracle a codé des milliers d'optimisations jusqu'à présent, en ajoutant plus d'optimisations dans chaque version de la base de données - mais il existe probablement beaucoup plus de milliers d'optimisations potentielles qu'elles ne doivent pas encore coder pour, en attendant que quelqu'un y pense.
@Jeffreykemp pourriez-vous élaborer pourquoi il n'est pas automatique dans ce cas? Pour moi, les deux déclarations sont sémantiquement égales (en cas de comptage des choses, l'ordre de ces choses n'a pas d'importance), par conséquent, Oracle pourrait simplement choisir l'un des index permettant de compter de toutes les lignes de la manière la plus efficace (par exemple, si est une colonne de clé primaire avec un type d'index efficace)
Oracle (la base de données) ne fera que quelque chose à moins que quelqu'un chez Oracle (le vendeur) écrit le code pour le faire. Ce n'est pas la magie.