Mysql
 sql >> Base de données >  >> RDS >> Mysql

MySQL/MariaDB - trier par sous-requête intérieure

Après quelques recherches, je peux confirmer vos deux scénarios :

MySQL 5.1 applique le ORDER BY à l'intérieur de la sous-requête.

MariaDB 5.5.39 sur Linux ne le fait pas appliquer le ORDER BY à l'intérieur de la sous-requête lorsqu'il n'y a pas de LIMIT est fourni. Ça fait cependant appliquer correctement la commande lorsqu'un LIMIT correspondant est donné :

SELECT t2.Code 
FROM (
  SELECT Country.Code FROM Country ORDER BY Country.Code DESC LIMIT 2
) AS t2;

Sans cette LIMIT , il n'y a pas de bonne raison d'appliquer le tri à l'intérieur de la sous-requête. Il peut être appliqué de manière équivalente à la requête externe.

Comportement documenté :

En fait, MariaDB a documenté ce comportement et ce n'est pas considéré comme un bogue :

Une "table" (et une sous-requête dans le FROM clause aussi) est - selon la norme SQL - un ensemble non ordonné de lignes. Lignes d'une table (ou d'une sous-requête dans le FROM clause) ne viennent pas dans un ordre spécifique. C'est pourquoi l'optimiseur peut ignorer le ORDER BY clause que vous avez spécifiée. En fait, le standard SQL n'autorise même pas le ORDER BY clause à apparaître dans cette sous-requête (nous l'autorisons, car ORDER BY ... LIMIT ... change le résultat, l'ensemble des lignes, pas seulement leur ordre).

Vous devez traiter la sous-requête dans le FROM clause, comme un ensemble de lignes dans un ordre non spécifié et indéfini, et mettez le ORDER BY au niveau supérieur SELECT .

MariaDB recommande donc également d'appliquer le ORDER BY dans la requête la plus externe, ou un LIMIT si nécessaire.

Remarque :Je n'ai actuellement pas accès à un MySQL 5.5 ou 5.6 approprié pour confirmer si le comportement y est le même (et que SQLFiddle.com fonctionne mal). Commentaires sur le rapport de bogue original (fermé car not-a-bug) suggèrent que MySQL 5.6 se comporte probablement de la même manière que MariaDB.