Quel est l'ordre par défaut d'une requête lorsqu'il n'y a pas d'ordre d'exécution ? ORDER BY
est utilisé ?
Réponses
Trop de publicités?Cet ordre n'existe pas. Tiré de http://forums.mysql.com/read.php?21,239471,239688#msg-239688
Ne pas dépendre de l'ordre lorsque ORDER BY est absent.
Spécifiez toujours ORDER BY si vous voulez un ordre particulier -- dans certaines situations le moteur peut éliminer le ORDER BY à cause de la façon dont il fait une autre étape.
GROUP BY force ORDER BY. (Ceci est une violation de la norme. Elle peut être évitée en utilisant ORDER BY NULL).
SELECT * FROM tbl
-- cela va faire un "scan de la table". Si la table n'a n'a jamais eu de DELETEs/REPLACEs/UPDATEs, les enregistrements se trouveront dans l'ordre d'insertion, d'où ce que vous avez observé.Si vous aviez fait la même déclaration avec une table InnoDB, ils auraient été livrés dans l'ordre des clés primaires et non dans l'ordre des insertions. dans l'ordre des clés primaires, et non dans l'ordre des insertions. Encore une fois, il s'agit d'un artefact de l'implémentation sous-jacente, et non d'un élément sur lequel il faut pas quelque chose dont il faut dépendre.
Il n'y en a pas. En fonction de ce que vous demandez et de la façon dont votre requête a été optimisée, vous pouvez obtenir n'importe quel ordre. Il n'y a même aucune garantie que deux requêtes qui se ressemblent renverront des résultats dans le même ordre : si vous ne le spécifiez pas, vous ne pouvez pas vous y fier.
J'ai constaté que le serveur SQL est presque aléatoire dans son ordre par défaut (en fonction de l'âge et de la complexité des données), ce qui est une bonne chose car cela vous oblige à spécifier tous les ordres.
(Je me souviens vaguement qu'Oracle était similaire à SQL Server à cet égard).
Par défaut, MySQL semble ordonner les données en fonction de la structure de l'enregistrement sur le disque (qui peut inclure des entrées non séquentielles en raison des suppressions et des optimisations), mais les développeurs sont souvent trompés au départ par le fait qu'ils ne prennent pas la peine d'utiliser des clauses order-by parce que les données semblent être ordonnées par défaut en fonction de la clé primaire, qui est pas l'affaire !
J'ai été surpris de découvrir aujourd'hui que MySQL 5.6 et 4.1 sous-ordonnent implicitement les enregistrements qui ont été triés sur une colonne avec une résolution limitée. dans le sens inverse . Certains de mes résultats ont des valeurs de tri identiques et l'ordre global est imprévisible. Par exemple, dans mon cas, il s'agissait d'un tri DESC par une colonne de date et certaines des entrées étaient dans la même seconde, donc elles ne pouvaient pas être explicitement ordonnées. Sur MySQL 5.6, ils sélectionnent dans un ordre (l'ordre d'insertion), mais dans 4.1, ils sélectionnent à l'envers ! Cela a conduit à un bug de déploiement très ennuyeux.
Je n'ai pas trouvé de documentation sur ce changement, mais j'ai trouvé notes sur sur implicite groupe commande dans MySQL :
Par défaut, MySQL trie toutes les requêtes GROUP BY col1, col2, ... comme si vous aviez également spécifié ORDER BY col1, col2, ... dans la requête.
Cependant :
L'utilisation du tri implicite GROUP BY dans MySQL 5.5 est dépréciée. Pour obtenir un ordre de tri spécifique des résultats groupés, il est préférable d'utiliser une clause ORDER BY explicite.
En accord avec les autres réponses, ne vous fiez jamais à l'ordre par défaut ou implicite dans une base de données.