Después de investigar un poco, puedo confirmar ambos escenarios:
MySQL 5.1 aplica el ORDER BY dentro de la subconsulta.
MariaDB 5.5.39 en Linux no aplicar el ORDER BY dentro de la subconsulta cuando no hay LIMIT es proporcionado. lo hace sin embargo, aplique correctamente el orden cuando un LIMIT correspondiente se da:
SELECT t2.Code
FROM (
SELECT Country.Code FROM Country ORDER BY Country.Code DESC LIMIT 2
) AS t2;
Sin ese LIMIT , no hay una buena razón para aplicar la ordenación dentro de la subconsulta. Se puede aplicar de manera equivalente a la consulta externa.
Comportamiento documentado:
Resulta que MariaDB ha documentado este comportamiento y no se considera un error:
Una "tabla" (y una subconsulta en FROM cláusula también) es, de acuerdo con el estándar SQL, un conjunto desordenado de filas. Filas en una tabla (o en una subconsulta en el FROM cláusula) no vienen en ningún orden específico. Es por eso que el optimizador puede ignorar el ORDER BY cláusula que ha especificado. De hecho, el estándar SQL ni siquiera permite el ORDER BY que aparezca en esta subconsulta (lo permitimos, porque ORDER BY ... LIMIT ... cambia el resultado, el conjunto de filas, no solo su orden).
Debe tratar la subconsulta en FROM cláusula, como un conjunto de filas en un orden no especificado e indefinido, y coloque el ORDER BY en el nivel superior SELECT .
Entonces MariaDB también recomienda aplicar el ORDER BY en la consulta más externa, o un LIMIT si es necesario.
Nota:actualmente no tengo acceso a un MySQL 5.5 o 5.6 adecuado para confirmar si el comportamiento es el mismo allí (y SQLFiddle.com no funciona correctamente). Comentarios sobre el informe de error original (cerrado como no-un-error) sugiere que MySQL 5.6 probablemente se comporte de la misma manera que MariaDB.
