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

Question

EDITAR:Todavía estoy esperando más respuestas. ¡Gracias!

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

Cuando SQL 2005 vino descubrí Row_Number() y lo he estado utilizando desde ...

Pero ahora, encontré un problema de rendimiento grave con Row_Number(). Funciona muy bien cuando trabajas con conjuntos de resultados no tan gigantescos y clasificas en una columna de identidad. Sin embargo, tiene un rendimiento muy bajo cuando trabaja con grandes conjuntos de resultados como más de 10.000 registros y clasificándolo sobre la columna sin 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í, se trataba de un punto donde se genera un error, "comando de tiempo de espera!"

¿Qué se usa para hacer paginate 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 using temp table with 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 lo que usas para 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 de antemano.

P.S. ¿Alguien sabe lo que usa stackoverflow?

EDIT: mina se ve algo 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 

postID: Int, Identidad (incremento automático), clave primaria

son posteriores: DateTime

EDIT: ¿Todos usan Row_Number()?

Answer 1

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 es de extrañar que consigue tiempos de espera.

Mi sugerencia: establecer un índice en una fecha posterior a DESC, esto es lo que ROW_NUMBER repasará - (ORDER BY DESC son posteriores, ...)

En cuanto al artículo que se está refiriendo a - He hecho bastante mucha paginación 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 es here.

.

Answer 2

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

¿Está utilizando row_number 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 el column_list y/o un índice en la columna 'OrderByColumnName'?