È VERAMENTE possibile che l'ordine non sia garantito per questa particolare tabella derivata ridondante?

Mi sono imbattuto in questa domanda in una conversazione su Twitter con Lukas Eder .

Sebbene il comportamento corretto sia applicare la clausola ORDER BY sulla query più esterna, poiché, qui, non stiamo usando DISTINCT, GROUP BY, JOIN o qualsiasi altra clausola WHERE nella query più esterna, perché un RDBMS non dovrebbe semplicemente passare la dati in arrivo come sono stati ordinati dalla query interna?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

Quando si esegue questo esempio su PostgreSQL, almeno si ottiene lo stesso piano di esecuzione sia per la query interna che per questo esempio di tabella derivata, nonché lo stesso set di risultati.

Quindi, suppongo che il Pianificatore eliminerà semplicemente la query più esterna perché è ridondante o semplicemente passa attraverso i risultati dalla tabella interna.

Qualcuno pensa che questo potrebbe non essere il caso?

La maggior parte dei database è abbastanza chiara sul fatto che ORDER BYin una sottoquery sia:

• Non consentito: ad esempio SQL Server, Sybase SQL Anywhere (a meno che non sia integrato con TOPo OFFSET .. FETCH)
• Senza significato: ad esempio PostgreSQL, DB2 (di nuovo, a meno che non sia integrato con OFFSET .. FETCHo LIMIT)

Ecco un esempio dal manuale DB2 LUW (l'enfasi è mia)

Una clausola ORDER BY in una sottoselezione non influisce sull'ordine delle righe restituite da una query. Una clausola ORDER BY ha effetto solo sull'ordine delle righe restituite se è specificata nella fullselect più esterna.

La formulazione è abbastanza esplicita, proprio come PostgreSQL :

Se non viene scelto l'ordinamento, le righe verranno restituite in un ordine non specificato. L'ordine effettivo in quel caso dipenderà dalla scansione e dai tipi di piano di join e dall'ordine su disco, ma non deve essere invocato . Un particolare ordinamento di output può essere garantito solo se la fase di ordinamento viene scelta esplicitamente.

Da questa specifica, si può seguire che qualsiasi ordinamento risultante dalla ORDER BYclausola in una tabella derivata è semplicemente accidentale e potrebbe coincidere casualmente con il tuo ordinamento previsto (cosa che fa nella maggior parte dei database nel tuo banale esempio), ma non sarebbe saggio fare affidamento su Questo.

Nota a margine su DB2:

In particolare, DB2 ha una funzione meno nota chiamataORDER BY ORDER OF <table-designator> , che può essere utilizzata come segue:

SELECT C1 FROM
   (SELECT C1 FROM T1
      UNION
    SELECT C1 FROM T2
    ORDER BY C1 ) AS UTABLE
ORDER BY ORDER OF UTABLE

In questo caso particolare, l'ordinamento della tabella derivata può essere riutilizzato esplicitamente nella parte più esterna di SELECT

Nota a margine su Oracle:

Per anni è stata una pratica in Oracle implementare l' OFFSETimpaginazione utilizzando ROWNUM, che può essere ragionevolmente calcolato solo dopo aver ordinato una tabella derivata:

SELECT *
FROM (
  SELECT rownum AS rn, t.* -- ROWNUM here depends on the derived table's ordering
  FROM (
    SELECT * FROM table ORDER BY time DESC
  ) t
) t
WHERE rn BETWEEN 10 AND 20

Ci si può ragionevolmente aspettare che, almeno in presenza di ROWNUMuna query, le future versioni di Oracle non interrompano questo comportamento al fine di non interrompere praticamente tutto il precedente SQL Oracle esistente, che non è ancora migrato verso il molto più desiderabile e OFFSET .. FETCHsintassi standard SQL leggibile :

SELECT * FROM table ORDER BY time DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY

Sì. Senza una ORDER BYclausola l'ordine di output non è definito e il pianificatore di query rientra nella sua sfera di competenza supponendo che tu lo sappia e lo capisca.

Può decidere che, poiché la query esterna non specifica un ordine, può eliminare l'ordinamento nella query interna per evitare un'operazione di ordinamento, soprattutto se non esiste alcun indice cluster o nessun indice a supporto dell'ordinamento. Se non lo fa ora si può fare nelle versioni future.

Non fare affidamento su comportamenti indefiniti. Se hai bisogno di un ordine specifico, dai una ORDER BYclausola nel posto appropriato.

È proprio il problema con un comportamento indefinito: funziona per te, funziona per me, riformatta l'HDD in prod;)

Possiamo fare un passo indietro e dire che, in un certo senso, hai ragione: non esiste alcun motivo terreno per cui un RDBMS sano riorganizzerebbe le file nella selezione interna. Ma non è garantito, il che significa che in futuro potrebbe esserci una ragione e i fornitori sono liberi di farlo. Ciò significa che qualsiasi codice che si basa su questo comportamento è in balia di una modifica che un fornitore potrebbe apportare e che non avrebbe l'obbligo di pubblicizzare, poiché non si tratta di una modifica sostanziale rispetto a un POV API.

È VERAMENTE possibile che l'ordine non sia garantito per questa particolare tabella derivata ridondante?

La risposta per tutte le versioni attualmente esistenti di Postgres (che stavi testando) è: No - per questa particolare query. L'ordinamento è garantito.

Le persone del server SQL non si sentiranno a proprio agio in quanto Microsoft non consente nemmeno ORDER BYnelle subquery. L'ordinamento è garantito per questa semplice query in Postgres. ORDER BYviene applicato nella sottoquery e la query esterna non esegue alcuna operazione che potrebbe modificare l'ordine.

Il manuale suggerisce anche tanto nel capitolo Funzioni aggregate :

In alternativa, in genere funzionerà fornendo i valori di input da una sottoquery ordinata.

Si noti che ciò è vero solo se i livelli di query esterni non aggiungono operazioni che potrebbero modificare l'ordine. Quindi è "garantito" solo per il caso semplice e non è supportato dallo standard SQL. Postgres è libero di riordinare se è opportuno per ulteriori operazioni. In caso di dubbio aggiungine un altro ORDER BYall'esterno SELECT. (Nel qual caso l'interno ORDER BYsarebbe rumore ridondante per questa semplice query.)