Na wat speurwerk kan ik beide scenario's bevestigen:
MySQL 5.1 past de ORDER BY
toe binnen de subquery.
MariaDB 5.5.39 op Linux doet niet pas de ORDER BY
. toe binnen de subquery wanneer geen LIMIT
is voorzien. Het doet pas de bestelling echter correct toe wanneer een overeenkomstige LIMIT
wordt gegeven:
SELECT t2.Code
FROM (
SELECT Country.Code FROM Country ORDER BY Country.Code DESC LIMIT 2
) AS t2;
Zonder die LIMIT
, is er geen goede reden om de sortering in de subquery toe te passen. Het kan op equivalente wijze worden toegepast op de buitenste vraag.
Gedocumenteerd gedrag:
Het blijkt dat MariaDB heeft dit gedrag gedocumenteerd en het wordt niet als een bug beschouwd:
Een "tabel" (en subquery in de
FROM
clausule) is - volgens de SQL-standaard - een ongeordende reeks rijen. Rijen in een tabel (of in een subquery in deFROM
clausule) komen niet in een specifieke volgorde. Daarom kan de optimizer deORDER BY
. negeren clausule die u hebt opgegeven. In feite staat de SQL-standaard zelfs deORDER BY
. niet toe clausule om in deze subquery te verschijnen (we staan het toe, omdatORDER BY ... LIMIT
... verandert het resultaat, de reeks rijen, niet alleen hun volgorde).U moet de subquery behandelen in de
FROM
clausule, als een reeks rijen in een niet-gespecificeerde en ongedefinieerde volgorde, en plaats deORDER BY
op het hoogste niveauSELECT
.
Dus MariaDB raadt ook aan om de ORDER BY
. toe te passen in de buitenste zoekopdracht, of een LIMIT
indien nodig.
Opmerking:ik heb momenteel geen toegang tot een goede MySQL 5.5 of 5.6 om te bevestigen of het gedrag daar hetzelfde is (en SQLFiddle.com werkt niet goed). Reacties op het originele bugrapport (gesloten als geen bug) suggereren dat MySQL 5.6 zich waarschijnlijk op dezelfde manier gedraagt als MariaDB.