¡Hola, chicos!

En esta publicación, me gustaría demostrarle cómo crear paginación de datos en SQL Server, de modo que las consultas solo devuelvan una cantidad limitada de registros, lo que hace que se procesen menos datos en la salida y las consultas tengan un tiempo de respuesta más corto. Este escenario es bastante común en aplicaciones, que tienden a paginar datos en la pantalla, tanto para evitar el exceso de información como para reducir el tiempo necesario para cargar la información.

Con la aparición de ROW_NUMBER() en SQL Server 2005, muchas personas comenzaron a utilizar esta función para crear paginación de datos, trabajando así:

DECLARE
    @Pagina INT = 5,
    @ItensPorPagina INT = 10


SELECT *
FROM (
    SELECT [name], ROW_NUMBER() OVER(ORDER BY [name]) AS Ranking
    FROM sys.objects
) A
WHERE 
    A.Ranking >= ((@Pagina - 1) * @ItensPorPagina) + 1 
    AND A.Ranking < (@Pagina * @ItensPorPagina) + 1

Resultado:

Sin embargo, a partir de SQL Server 2012, tenemos la funcionalidad de paginación nativa en el propio SQL Server, que muchas personas terminan por no utilizar por falta de conocimiento. Estamos hablando de las funciones OFFSET y FETCH, que funcionan juntas para permitirnos paginar nuestros resultados antes de mostrarlos y enviarlos a aplicaciones y clientes.

Mira cómo se usa, es simple:

SELECT [name]
FROM sys.objects
ORDER BY [name]
OFFSET 40 ROWS -- Linha de início: Vai começar a retornar a partir da linha 40
  FETCH NEXT 10 ROWS ONLY -- Quantidade de linhas para retornar: Vai retornar as próximas 10 linhas

Resultado:

Y si queremos algo parametrizable, como en el ejemplo anterior, podemos usar la misma estructura que el ejemplo anterior:

DECLARE
    @Pagina INT = 5,
    @ItensPorPagina INT = 10

SELECT [name]
FROM sys.objects
ORDER BY [name]
OFFSET (@Pagina - 1) * @ItensPorPagina ROWS
  FETCH NEXT @ItensPorPagina ROWS ONLY

Analicemos ahora el rendimiento de las dos consultas para ver si, además de facilidad, tenemos alguna ventaja en términos de rendimiento:

Plan de ejecución: ROW_NUMBER()

Plan de ejecución: OFFSET y FETCH

Analizando el plan de ejecución, la solución con OFFSET y FETCH parece utilizar menos operadores y presentar un plan más simple. Ahora veamos los números en la práctica:

Voy a cambiar las consultas e intentar ordenar por una columna VARCHAR, no indexada, para comprobar si hay algún cambio en el rendimiento de las 2 soluciones:

Bueno, analizando los resultados de las pruebas que realicé, quedó claro que, aunque esta solución es más práctica de implementar, se queda un poco atrás en términos de rendimiento.

Creo que en un escenario real del día a día, esta diferencia de rendimiento termina no siendo tan relevante (dependiendo del uso de la aplicación), pero aquí hay un consejo sobre la relación costo-beneficio entre practicidad y rendimiento al usar la paginación en SQL Server con ROW_NUMBER() o OFFSET + FETCH. Si quieres profundizar en el análisis de rendimiento de OFFSET + FETCH, te recomiendo leer el artículo Paginación con OFFSET/FETCH: una mejor manera, de Aarón Bertrand.

Espero que les haya gustado esta publicación, donde presenté cómo crear paginación de datos en SQL Server usando ROW_NUMBER() o OFFSET + FETCH NEXT n ROWS SOLAMENTE.
Un abrazo y ¡hasta la próxima!