Numeri di riga con ordine non deterministico

La conclusione è che dovresti ordinare in base a espressioni che non sono costanti. Ovviamente, puoi ordinare in base a un elenco di colonne dalle tabelle interrogate. Ma siamo alla ricerca di una soluzione efficiente in cui l'ottimizzatore possa rendersi conto che non c'è alcuna rilevanza nell'ordine.

Piegatura costante

La conclusione finora è che non è possibile utilizzare le costanti nella clausola dell'ordine della finestra di ROW_NUMBER, ma per quanto riguarda le espressioni basate su costanti, come nella seguente query:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 1+0) AS n 
FROM dbo.T1;

Tuttavia, questo tentativo è vittima di un processo noto come ripiegamento costante, che normalmente ha un impatto positivo sulle prestazioni delle query. L'idea alla base di questa tecnica è di migliorare le prestazioni della query piegando alcune espressioni basate sulle costanti alle costanti dei risultati in una fase iniziale dell'elaborazione della query. Puoi trovare i dettagli su quali tipi di espressioni possono essere piegati in modo costante qui. La nostra espressione 1+0 è piegata a 1, risultando nello stesso errore che hai ottenuto specificando direttamente la costante 1:

Dovresti affrontare una situazione simile quando tenti di concatenare due stringhe di caratteri letterali, in questo modo:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 'No' + ' Order') AS n 
FROM dbo.T1;

Ottieni lo stesso errore che hai ottenuto specificando direttamente il letterale "Nessun ordine":

Mondo bizzarro:errori che prevengono gli errori

La vita è piena di sorprese...

Una cosa che impedisce la piegatura costante è quando l'espressione normalmente risulterebbe in un errore. Ad esempio, l'espressione 2147483646+1 può essere piegata in modo costante poiché risulta in un valore di tipo INT valido. Di conseguenza, un tentativo di eseguire la query seguente non riesce:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 2147483646+1) AS n 
FROM dbo.T1;

Tuttavia, l'espressione 2147483647+1 non può essere piegata in modo costante perché tale tentativo avrebbe comportato un errore di overflow INT. L'implicazione sull'ordinazione è piuttosto interessante. Prova la seguente query (la chiameremo Query 2):

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 2147483647+1) AS n 
FROM dbo.T1;

Stranamente, questa query viene eseguita correttamente! Quello che succede è che da un lato, SQL Server non riesce ad applicare la piegatura costante e quindi l'ordinamento si basa su un'espressione che non è una singola costante. D'altra parte, l'ottimizzatore calcola che il valore di ordinamento è lo stesso per tutte le righe, quindi ignora del tutto l'espressione di ordinamento. Ciò viene confermato durante l'esame del piano per questa query, come mostrato nella Figura 3.

Figura 3:piano per la query 2

Osservare che il piano esegue la scansione di alcuni indici di copertura con una proprietà Ordered:False. Questo era esattamente il nostro obiettivo di rendimento.

In modo simile, la query seguente implica un tentativo di piegatura costante riuscito e pertanto non riesce:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 1/1) AS n 
FROM dbo.T1;

La query seguente implica un tentativo di ripiegamento costante fallito e quindi riesce, generando il piano mostrato in precedenza nella Figura 3:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 1/0) AS n 
FROM dbo.T1;

La query seguente implica un tentativo di piegatura costante riuscito (il valore letterale VARCHAR '1' viene convertito in modo implicito in INT 1 e quindi 1 + 1 viene piegato a 2) e pertanto non riesce:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 1+'1') AS n 
FROM dbo.T1;

La query seguente implica un tentativo di piegatura costante fallito (non è possibile convertire 'A' in INT) e quindi riesce, generando il piano mostrato in precedenza nella Figura 3:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY 1+'A') AS n 
FROM dbo.T1;

Ad essere onesti, anche se questa tecnica bizzarra raggiunge il nostro obiettivo di prestazione originale, non posso dire di considerarla sicura e quindi non mi sento così a mio agio a fare affidamento su di essa.

Costanti di runtime basate su funzioni

Continuando la ricerca di una buona soluzione per calcolare i numeri di riga con ordine non deterministico, ci sono alcune tecniche che sembrano più sicure dell'ultima soluzione bizzarra:usare costanti di runtime basate su funzioni, usare una sottoquery basata su una costante, usare una colonna con alias basata su una costante e usando una variabile.

Come spiego in T-SQL bug, insidie ​​e best practice - determinismo, la maggior parte delle funzioni in T-SQL vengono valutate solo una volta per riferimento nella query, non una volta per riga. Questo è il caso anche con la maggior parte delle funzioni non deterministiche come GETDATE e RAND. Ci sono pochissime eccezioni a questa regola, come le funzioni NEWID e CRYPT_GEN_RANDOM, che vengono valutate una volta per riga. La maggior parte delle funzioni, come GETDATE, @@SPID e molte altre, vengono valutate una volta all'inizio della query e i loro valori vengono quindi considerati costanti di runtime. Un riferimento a tali funzioni non viene piegato in modo costante. Queste caratteristiche rendono una costante di runtime basata su una funzione una buona scelta come elemento di ordinamento delle finestre e, in effetti, sembra che T-SQL la supporti. Allo stesso tempo, l'ottimizzatore si rende conto che in pratica non c'è pertinenza nell'ordine, evitando inutili penalizzazioni delle prestazioni.

Ecco un esempio usando la funzione GETDATE:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY GETDATE()) AS n 
FROM dbo.T1;

Questa query ottiene lo stesso piano mostrato in precedenza nella Figura 3.

Ecco un altro esempio che utilizza la funzione @@SPID (restituendo l'ID della sessione corrente):

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY @@SPID) AS n 
FROM dbo.T1;

E la funzione PI? Prova la seguente query:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY PI()) AS n 
FROM dbo.T1;

Questo non riesce con il seguente errore:

Funzioni come GETDATE e @@SPID vengono rivalutate una volta per esecuzione del piano, quindi non possono essere costantemente piegate. PI rappresenta sempre la stessa costante e quindi viene piegata in modo costante.

Come accennato in precedenza, ci sono pochissime funzioni che vengono valutate una volta per riga, come NEWID e CRYPT_GEN_RANDOM. Questo li rende una cattiva scelta come elemento di ordinamento delle finestre se hai bisogno di un ordine non deterministico, da non confondere con l'ordine casuale. Perché pagare una sanzione di smistamento non necessaria?

Ecco un esempio di utilizzo della funzione NEWID:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY NEWID()) AS n 
FROM dbo.T1;

Il piano per questa query è mostrato nella Figura 4, a conferma che SQL Server ha aggiunto l'ordinamento esplicito in base al risultato della funzione.

Figura 4:piano per la query 3

Se vuoi che i numeri di riga vengano assegnati in ordine casuale, questa è la tecnica che vuoi usare. Devi solo essere consapevole del fatto che comporta il costo di ordinamento.

Utilizzo di una sottoquery

È inoltre possibile utilizzare una sottoquery basata su una costante come espressione di ordinamento delle finestre (ad es. ORDER BY (SELECT 'No Order')). Anche con questa soluzione, l'ottimizzatore di SQL Server riconosce che non c'è alcuna rilevanza per l'ordine e quindi non impone un ordinamento non necessario né limita le scelte del motore di archiviazione a quelle che devono garantire l'ordine. Prova a eseguire la seguente query come esempio:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY (SELECT 'No Order')) AS n 
FROM dbo.T1;

Ottieni lo stesso piano mostrato in precedenza nella Figura 3.

Uno dei grandi vantaggi di questa tecnica è che puoi aggiungere il tuo tocco personale. Forse ti piacciono molto i NULL:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS n 
FROM dbo.T1;

Forse ti piace molto un certo numero:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY (SELECT 42)) AS n 
FROM dbo.T1;

Forse vuoi mandare un messaggio a qualcuno:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY (SELECT 'Lilach, will you marry me?')) AS n 
FROM dbo.T1;

Hai capito.

Fattibile, ma imbarazzante

Ci sono un paio di tecniche che funzionano, ma sono un po' imbarazzanti. Uno consiste nel definire un alias di colonna per un'espressione basata su una costante, quindi utilizzare quell'alias di colonna come elemento di ordinamento della finestra. Puoi farlo usando un'espressione di tabella o con l'operatore CROSS APPLY e un costruttore di valori di tabella. Ecco un esempio per quest'ultimo:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY [I'm a bit ugly]) AS n 
FROM dbo.T1 CROSS APPLY ( VALUES('No Order') ) AS A([I'm a bit ugly]);

Ottieni lo stesso piano mostrato in precedenza nella Figura 3.

Un'altra opzione consiste nell'usare una variabile come elemento di ordinamento delle finestre:

DECLARE @ImABitUglyToo AS INT = NULL;
 
SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY @ImABitUglyToo) AS n 
FROM dbo.T1;

Questa query ottiene anche il piano mostrato in precedenza nella Figura 3.

Cosa succede se utilizzo la mia UDF?

Potresti pensare che usare la tua UDF che restituisce una costante potrebbe essere una buona scelta come elemento di ordinamento della finestra quando desideri un ordine non deterministico, ma non lo è. Considera la seguente definizione UDF come esempio:

DROP FUNCTION IF EXISTS dbo.YouWillRegretThis;
GO
 
CREATE FUNCTION dbo.YouWillRegretThis() RETURNS INT
AS
BEGIN
  RETURN NULL
END;
GO

Prova a utilizzare l'UDF come clausola di ordinamento delle finestre, in questo modo (la chiameremo Query 4):

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(ORDER BY dbo.YouWillRegretThis()) AS n 
FROM dbo.T1;

Prima di SQL Server 2019 (o livello di compatibilità parallela <150), le funzioni definite dall'utente vengono valutate per riga. Anche se restituiscono una costante, non vengono allineati. Di conseguenza, da un lato è possibile utilizzare tale UDF come elemento di ordinamento delle finestre, ma dall'altro ciò si traduce in una penalità di ordinamento. Ciò è confermato esaminando il piano per questa query, come mostrato nella Figura 5.

Figura 5:piano per la query 4

A partire da SQL Server 2019, con livello di compatibilità>=150, tali funzioni definite dall'utente vengono integrate, il che è principalmente un'ottima cosa, ma nel nostro caso si verifica un errore:

Pertanto, l'utilizzo di una UDF basata su una costante come elemento di ordinamento della finestra forza un ordinamento o un errore a seconda della versione di SQL Server in uso e del livello di compatibilità del database. In breve, non farlo.

Numeri di riga partizionati con ordine non deterministico

Un caso d'uso comune per i numeri di riga partizionati in base all'ordine non deterministico restituisce qualsiasi riga per gruppo. Dato che per definizione esiste un elemento di partizionamento in questo scenario, si potrebbe pensare che una tecnica sicura in tal caso sarebbe quella di utilizzare l'elemento di partizionamento della finestra anche come elemento di ordinamento delle finestre. Come primo passo, calcoli i numeri di riga in questo modo:

SELECT id, grp, datacol,
  ROW_NUMBER() OVER(PARTITION BY grp ORDER BY grp) AS n 
FROM dbo.T1;

Il piano per questa query è mostrato nella Figura 6.

Figura 6:piano per la query 5

Il motivo per cui il nostro indice di supporto viene scansionato con una proprietà Ordered:True è perché SQL Server deve elaborare le righe di ogni partizione come una singola unità. Questo è il caso prima del filtraggio. Se filtri solo una riga per partizione, hai come opzioni sia gli algoritmi basati sugli ordini che quelli basati sugli hash.

Il secondo passaggio consiste nel posizionare la query con il calcolo del numero di riga in un'espressione di tabella e nella query esterna filtrare la riga con il numero di riga 1 in ciascuna partizione, in questo modo:

WITH C AS
(
  SELECT id, grp, datacol,
    ROW_NUMBER() OVER(PARTITION BY grp ORDER BY grp) AS n 
  FROM dbo.T1
)
SELECT id, grp, datacol
FROM C
WHERE n = 1;

Teoricamente questa tecnica dovrebbe essere sicura, ma Paul White ha trovato un bug che mostra che usando questo metodo puoi ottenere attributi da diverse righe di origine nella riga dei risultati restituita per partizione. L'uso di una costante di runtime basata su una funzione o di una sottoquery basata su una costante come elemento di ordinamento sembra essere sicuro anche in questo scenario, quindi assicurati di utilizzare invece una soluzione come la seguente:

WITH C AS
(
  SELECT id, grp, datacol,
    ROW_NUMBER() OVER(PARTITION BY grp ORDER BY (SELECT 'No Order')) AS n 
  FROM dbo.T1
)
SELECT id, grp, datacol
FROM C
WHERE n = 1;

Nessuno passerà da questa parte senza il mio permesso

Cercare di calcolare i numeri di riga in base a un ordine non deterministico è un'esigenza comune. Sarebbe stato bello se T-SQL avesse semplicemente reso facoltativa la clausola dell'ordine della finestra per la funzione ROW_NUMBER, ma non è così. In caso contrario, sarebbe stato bello se almeno consentisse l'utilizzo di una costante come elemento di ordinamento, ma nemmeno questa è un'opzione supportata. Ma se chiedi gentilmente, sotto forma di una sottoquery basata su una costante o una costante di runtime basata su una funzione, SQL Server lo consentirà. Queste sono le due opzioni con cui sono più a mio agio. Non mi sento davvero a mio agio con le strane espressioni errate che sembrano funzionare, quindi non posso raccomandare questa opzione.