Efter lite grävande kan jag bekräfta båda dina scenarier:
MySQL 5.1 tillämpar ORDER BY
inuti underfrågan.
MariaDB 5.5.39 på Linux gör det inte tillämpa ORDER BY
inuti underfrågan när ingen LIMIT
Levereras. Det gör tillämpa dock ordern korrekt när en motsvarande LIMIT
ges:
SELECT t2.Code
FROM (
SELECT Country.Code FROM Country ORDER BY Country.Code DESC LIMIT 2
) AS t2;
Utan den LIMIT
, finns det ingen bra anledning att tillämpa sorteringen i underfrågan. Det kan appliceras på motsvarande sätt på den yttre frågan.
Dokumenterat beteende:
Som det visar sig, MariaDB har dokumenterat detta beteende och det betraktas inte som en bugg:
En "tabell" (och underfråga i
FROM
även) är - enligt SQL-standarden - en oordnad uppsättning rader. Rader i en tabell (eller i en underfråga iFROM
). klausul) kommer inte i någon specifik ordning. Det är därför optimeraren kan ignoreraORDER BY
klausul som du har specificerat. Faktum är att SQL-standarden inte ens tillåterORDER BY
sats som visas i den här underfrågan (vi tillåter det eftersomORDER BY ... LIMIT
... ändrar resultatet, uppsättningen av rader, inte bara deras ordning).Du måste behandla underfrågan i
FROM
sats, som en uppsättning rader i någon ospecificerad och odefinierad ordning, och sättORDER BY
på toppnivånSELECT
.
Så MariaDB rekommenderar också att du använder ORDER BY
i den yttersta frågan, eller en LIMIT
vid behov.
Obs:Jag har för närvarande inte tillgång till en riktig MySQL 5.5 eller 5.6 för att bekräfta om beteendet är detsamma där (och SQLFiddle.com fungerar inte). Kommentarer på den ursprungliga felrapporten (stängd som inte-en-bugg) tyder på att MySQL 5.6 förmodligen beter sig på samma sätt som MariaDB.