Números de fila con orden no determinista

La conclusión es que se supone que debes ordenar por expresiones que no son constantes. Obviamente, puede ordenar por una lista de columnas de la(s) tabla(s) consultada(s). Pero estamos en una búsqueda para encontrar una solución eficiente donde el optimizador pueda darse cuenta de que no hay relevancia en los pedidos.

Plegado constante

La conclusión hasta ahora es que no puede usar constantes en la cláusula de orden de ventana de ROW_NUMBER, pero ¿qué pasa con las expresiones basadas en constantes, como en la siguiente consulta:

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

Sin embargo, este intento es víctima de un proceso conocido como plegamiento constante, que normalmente tiene un impacto positivo en el rendimiento de las consultas. La idea detrás de esta técnica es mejorar el rendimiento de las consultas plegando alguna expresión basada en constantes a sus constantes de resultado en una etapa temprana del procesamiento de la consulta. Puede encontrar detalles sobre qué tipos de expresiones se pueden doblar constantemente aquí. Nuestra expresión 1+0 se pliega a 1, lo que da como resultado el mismo error que obtuvo al especificar la constante 1 directamente:

Te enfrentarías a una situación similar al intentar concatenar dos cadenas de caracteres literales, así:

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

Obtiene el mismo error que obtuvo al especificar el literal 'Sin orden' directamente:

Mundo bizarro:errores que evitan errores

La vida está llena de sorpresas...

Una cosa que evita el plegado constante es cuando la expresión normalmente resultaría en un error. Por ejemplo, la expresión 2147483646+1 se puede doblar constantemente ya que da como resultado un valor de tipo INT válido. En consecuencia, falla un intento de ejecutar la siguiente consulta:

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

Sin embargo, la expresión 2147483647+1 no puede doblarse constantemente porque tal intento habría resultado en un error de desbordamiento de INT. La implicación en el pedido es bastante interesante. Pruebe la siguiente consulta (la llamaremos Consulta 2):

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

Curiosamente, ¡esta consulta se ejecuta correctamente! Lo que sucede es que por un lado SQL Server no logra aplicar el plegamiento de constantes, y por lo tanto el ordenamiento se basa en una expresión que no es una sola constante. Por otro lado, el optimizador calcula que el valor de ordenación es el mismo para todas las filas, por lo que ignora la expresión de ordenación por completo. Esto se confirma al examinar el plan para esta consulta como se muestra en la Figura 3.

Figura 3:Plan para la consulta 2

Observe que el plan escanea algún índice de cobertura con una propiedad Ordenado:Falso. Este era exactamente nuestro objetivo de rendimiento.

De manera similar, la siguiente consulta implica un intento de plegamiento constante exitoso y, por lo tanto, falla:

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

La siguiente consulta implica un intento fallido de plegado constante y, por lo tanto, tiene éxito, generando el plan que se muestra anteriormente en la Figura 3:

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

La siguiente consulta implica un intento exitoso de plegado constante (el literal '1' de VARCHAR se convierte implícitamente a INT 1 y luego 1 + 1 se pliega a 2) y, por lo tanto, falla:

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

La siguiente consulta implica un intento de plegado constante fallido (no se puede convertir 'A' en INT) y, por lo tanto, tiene éxito, generando el plan que se muestra anteriormente en la Figura 3:

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

Para ser honesto, a pesar de que esta técnica extraña logra nuestro objetivo de rendimiento original, no puedo decir que la considere segura y, por lo tanto, no me siento tan cómodo confiando en ella.

Constantes de ejecución basadas en funciones

Continuando con la búsqueda de una buena solución para calcular números de fila con un orden no determinista, existen algunas técnicas que parecen más seguras que la última solución peculiar:usar constantes de tiempo de ejecución basadas en funciones, usar una subconsulta basada en una constante, usar una columna con alias basada en una constante y usando una variable.

Como explico en Errores, trampas y mejores prácticas de T-SQL:determinismo, la mayoría de las funciones en T-SQL se evalúan solo una vez por referencia en la consulta, no una vez por fila. Este es el caso incluso con la mayoría de las funciones no deterministas como GETDATE y RAND. Hay muy pocas excepciones a esta regla, como las funciones NEWID y CRYPT_GEN_RANDOM, que se evalúan una vez por fila. La mayoría de las funciones, como GETDATE, @@SPID y muchas otras, se evalúan una vez al comienzo de la consulta y sus valores se consideran constantes de tiempo de ejecución. Una referencia a tales funciones no se pliega constantemente. Estas características hacen que una constante de tiempo de ejecución que se basa en una función sea una buena opción como elemento de ordenación de ventanas y, de hecho, parece que T-SQL lo admite. Al mismo tiempo, el optimizador se da cuenta de que en la práctica no hay relevancia en los pedidos, lo que evita penalizaciones de rendimiento innecesarias.

Aquí hay un ejemplo usando la función GETDATE:

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

Esta consulta obtiene el mismo plan que se muestra anteriormente en la Figura 3.

Aquí hay otro ejemplo que usa la función @@SPID (que devuelve el ID de la sesión actual):

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

¿Qué pasa con la función PI? Pruebe la siguiente consulta:

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

Este falla con el siguiente error:

Funciones como GETDATE y @@SPID se vuelven a evaluar una vez por ejecución del plan, por lo que no se pueden doblar constantemente. PI representa siempre la misma constante y, por lo tanto, se pliega constantemente.

Como se mencionó anteriormente, hay muy pocas funciones que se evalúan una vez por fila, como NEWID y CRYPT_GEN_RANDOM. Esto los convierte en una mala elección como elemento de ordenación de ventanas si necesita un orden no determinista, que no debe confundirse con un orden aleatorio. ¿Por qué pagar una penalización por clasificación innecesaria?

Aquí hay un ejemplo usando la función NEWID:

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

El plan para esta consulta se muestra en la Figura 4, lo que confirma que SQL Server agregó una clasificación explícita basada en el resultado de la función.

Figura 4:Plan para Consulta 3

Si desea que los números de fila se asignen en orden aleatorio, por supuesto, esa es la técnica que desea utilizar. Solo debe tener en cuenta que incurre en el costo de clasificación.

Usando una subconsulta

También puede utilizar una subconsulta basada en una constante como expresión de ordenación de ventanas (p. ej., ORDENAR POR (SELECCIONAR 'Sin orden')). Además, con esta solución, el optimizador de SQL Server reconoce que no hay relevancia en el pedido y, por lo tanto, no impone una ordenación innecesaria ni limita las opciones del motor de almacenamiento a las que deben garantizar el orden. Intente ejecutar la siguiente consulta como ejemplo:

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

Obtiene el mismo plan que se muestra anteriormente en la Figura 3.

Uno de los grandes beneficios de esta técnica es que puedes añadir tu propio toque personal. Tal vez realmente te gusten los valores NULL:

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

Tal vez te guste mucho cierto número:

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

Tal vez quieras enviarle un mensaje a alguien:

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

Entiendes el punto.

Factible, pero incómodo

Hay un par de técnicas que funcionan, pero son un poco incómodas. Una es definir un alias de columna para una expresión basada en una constante y luego usar ese alias de columna como el elemento de ordenación de la ventana. Puede hacerlo usando una expresión de tabla o con el operador CROSS APPLY y un constructor de valores de tabla. Aquí hay un ejemplo para este último:

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]);

Obtiene el mismo plan que se muestra anteriormente en la Figura 3.

Otra opción es usar una variable como elemento de ordenación de ventanas:

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

Esta consulta también obtiene el plan que se muestra anteriormente en la Figura 3.

¿Qué pasa si uso mi propio UDF?

Podría pensar que usar su propia UDF que devuelve una constante podría ser una buena opción como elemento de ordenación de ventanas cuando desea un orden no determinista, pero no lo es. Considere la siguiente definición de UDF como ejemplo:

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

Intente usar el UDF como la cláusula de ordenación de ventanas, así (a esta la llamaremos Consulta 4):

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

Antes de SQL Server 2019 (o nivel de compatibilidad paralela <150), las funciones definidas por el usuario se evaluaban por fila. Incluso si devuelven una constante, no se alinean. En consecuencia, por un lado, puede usar un UDF como el elemento de ordenación de ventanas, pero por otro lado, esto da como resultado una penalización de clasificación. Esto se confirma examinando el plan para esta consulta, como se muestra en la Figura 5.

Figura 5:Plan para Consulta 4

A partir de SQL Server 2019, con un nivel de compatibilidad>=150, estas funciones definidas por el usuario se integran, lo que en su mayoría es una gran cosa, pero en nuestro caso da como resultado un error:

Por lo tanto, usar una UDF basada en una constante como elemento de ordenación de ventanas fuerza una ordenación o un error según la versión de SQL Server que esté usando y el nivel de compatibilidad de su base de datos. En resumen, no hagas esto.

Números de fila particionados con orden no determinista

Un caso de uso común para números de fila particionados basados ​​en un orden no determinista es devolver cualquier fila por grupo. Dado que, por definición, existe un elemento de partición en este escenario, pensaría que una técnica segura en tal caso sería utilizar el elemento de partición de ventana también como elemento de ordenación de ventana. Como primer paso, calcula números de fila así:

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

El plan para esta consulta se muestra en la Figura 6.

Figura 6:Plan para Consulta 5

La razón por la que nuestro índice de soporte se escanea con una propiedad Ordered:True es porque SQL Server necesita procesar las filas de cada partición como una sola unidad. Ese es el caso antes de filtrar. Si filtra solo una fila por partición, tiene como opciones algoritmos basados ​​en orden y basados ​​en hash.

El segundo paso es colocar la consulta con el cálculo del número de fila en una expresión de tabla y, en la consulta externa, filtrar la fila con el número de fila 1 en cada partición, así:

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;

Teóricamente, se supone que esta técnica es segura, pero Paul White encontró un error que muestra que con este método puede obtener atributos de diferentes filas de origen en la fila de resultados devuelta por partición. El uso de una constante de tiempo de ejecución basada en una función o una subconsulta basada en una constante como elemento de pedido parece ser seguro incluso en este escenario, así que asegúrese de usar una solución como la siguiente:

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;

Nadie pasará por aquí sin mi permiso

Tratar de calcular números de fila en función de un orden no determinista es una necesidad común. Hubiera sido bueno si T-SQL simplemente hiciera que la cláusula de orden de ventana fuera opcional para la función ROW_NUMBER, pero no es así. Si no, hubiera sido bueno si al menos permitiera usar una constante como elemento de pedido, pero esa tampoco es una opción admitida. Pero si lo pide amablemente, en forma de una subconsulta basada en una constante o una constante de tiempo de ejecución basada en una función, SQL Server lo permitirá. Estas son las dos opciones con las que me siento más cómoda. Realmente no me siento cómodo con las extravagantes expresiones erróneas que parecen funcionar, así que no puedo recomendar esta opción.