sql-server-2005 - smallint - tipos de datos en sql server

¿Cuál es un método eficiente de paginación a través de conjuntos de resultados muy grandes en SQL Server 2005?

Question

EDIT: todavía estoy esperando por más respuestas. ¡Gracias!

En SQL 2000 días, solía usar el método de tabla temporal donde se crea una tabla temporal con una nueva columna de identidad y una clave principal y luego se selecciona la columna de identidad entre A y B.

Cuando apareció SQL 2005 descubrí Row_Number() y lo he estado usando desde entonces ...

Pero ahora, encontré un serio problema de rendimiento con Row_Number() . Funciona muy bien cuando se trabaja con conjuntos de resultados no tan gigantescos y se clasifica en una columna de identidad. Sin embargo, tiene un rendimiento muy bajo cuando se trabaja con grandes conjuntos de resultados, como más de 10,000 registros, y se clasifica en una columna que no sea de identidad . Row_Number() funciona mal incluso si ordena por una columna de identidad si el conjunto de resultados es más de 250,000 registros. Para mí, llegó a un punto en el que arroja un error, " command timeout! "

¿Qué utilizas para paginar un gran conjunto de resultados en SQL 2005? ¿El método de tabla temporal es aún mejor en este caso? No estoy seguro de si este método que utiliza la tabla temporal con SET ROWCOUNT funcionará mejor ... Pero algunos dicen que hay un problema de dar un número de fila incorrecto si tiene una clave primaria de múltiples columnas.

En mi caso, necesito poder ordenar el conjunto de resultados por una columna de tipo de fecha ... para mi aplicación web de producción.

Déjame saber qué usas para la paginación de alto rendimiento en SQL 2005 . Y también me gustaría saber una forma inteligente de crear índices. Sospecho que elegir claves primarias correctas y / o índices (agrupados / no agrupados) jugará un papel importante aquí.

Gracias por adelantado.

PD: ¿Alguien sabe lo que usa stackoverflow?

EDITAR: El mío se ve algo así como ...

SELECT postID, postTitle, postDate
FROM
   (SELECT postID, postTitle, postDate, 
         ROW_NUMBER() OVER(ORDER BY postDate DESC, postID DESC) as RowNum
    FROM MyTable
   ) as DerivedMyTable
WHERE RowNum BETWEEN @startRowIndex AND (@startRowIndex + @maximumRows) - 1

ID de publicación: Int, Identidad (autoincremento), Clave principal

postDate: DateTime

EDITAR: ¿Todos usan Row_Number ()?

Answer 1

La técnica row_number () debe ser rápida. He visto buenos resultados para 100.000 filas.

¿Está utilizando row_number () de forma similar a lo siguiente?

SELECT column_list
FROM
   (SELECT column_list
         ROW_NUMBER() OVER(ORDER BY OrderByColumnName) as RowNum
    FROM MyTable m
   ) as DerivedTableName
WHERE RowNum BETWEEN @startRowIndex AND (@startRowIndex + @maximumRows) - 1

... y ¿tiene un índice de cobertura para column_list y / o un índice en la columna ''OrderByColumnName''?

Answer 2

Bueno, para su consulta de muestra, ROW_COUNT debería ser bastante rápido con miles de filas, siempre que tenga un índice en su campo PostDate. Si no lo hace, el servidor necesita realizar un análisis de índice agrupado completo en su PK, prácticamente cargar cada página, buscar su campo PostDate, ordenar por él, determinar las filas para extraer para el conjunto de resultados y volver a buscar esas filas. Es como crear un índice temporal una y otra vez (es posible que vea una tabla / cola de índice en el plano).

No me extraña que tengas tiempos de espera.

Mi sugerencia: establecer un índice en PostDate DESC, esto es lo que ROW_NUMBER repasará - (ORDER BY PostDate DESC, ...)

En cuanto al artículo al que te refieres, ya he hecho casi megafonía y cosas con SQL Server 2000 en el pasado sin ROW_COUNT y el enfoque utilizado en el artículo es el más eficiente. No funciona en todas las circunstancias (necesita valores únicos o casi únicos). Una visión general de algunos otros métodos está aquí .

.