SQL Server 2008: ordenar por fecha y hora es demasiado lento

Question

Mi tabla (SQL Server 2008) tiene más de 1 millón de registros, cuando intento ordenar registros por fecha y hora, demora 1 segundo, pero cuando ordeno por ID (int), solo toma alrededor de 0.1 segundo.

¿Hay alguna manera de mejorar la eficiencia? (Ya agregué la columna de fecha y hora en el índice)

Answer 1

Realizando su pedido por id probablemente utilice un análisis de índice agrupado mientras ordena por datetime utiliza la búsqueda de clasificación o de índice.

Ambos métodos son más lentos que un análisis de índice agrupado.

Si su tabla está agrupada por id, básicamente significa que ya está ordenada. Los registros están contenidos en un B+Tree que tiene una lista vinculada que vincula las páginas en el orden id. El motor solo debe atravesar la lista vinculada para obtener los registros ordenados por id.

Si se insertaron id s en orden secuencial, esto significa que el orden físico de las filas coincidirá con el orden lógico y el análisis de índice agrupado será aún más rápido.

Si desea que sus registros a ser ordenados por datetime, hay dos opciones:

• tomar todas las fichas de la mesa y ordenarlos. La lentitud es obvia.
• Utilice el índice en datetime. El índice se almacena en un espacio separado del disco, lo que significa que el motor debe desplazarse entre las páginas de índice y las páginas de la tabla en un bucle anidado. Es más lento también.

A fin de mejorar la ordenación, se puede crear un índice de cobertura separada sobre datetime:

CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …) 

, e incluyen todas las columnas que utiliza en su consulta en ese índice.

Este índice es como una instantánea de su tabla pero con datos ordenados en orden diferente.

Esto le permitirá deshacerse de las búsquedas de claves (dado que el índice contiene todos los datos) lo que hará que el pedido sea datetime tan rápido como en id.

Actualización:

un blog fresco sobre este problema:

• SQL Server: clustered index and ordering

Answer 2

tal vez si almacena DataTime como int, pero se necesitaría mucho tiempo convirtiendo cada vez que se almacenar u obtener datos. (técnica común utilizada para personal de la tienda como la dirección IP y tienen unas buscar más rápido veces)

debe verificar en el servidor de cómo se almacena la fecha y hora, b/c su servidor ya se almacena como int o bigint .. lo hará no cambia nada ...

Answer 3

Agregue el tiempo de fecha a un nuevo índice, y al agregarlo a la identificación uno no ayudará mucho.

Answer 4

Si su campo de fecha y hora contiene muchos valores distintos y esos valores raramente cambian, defina un índice agrupado en el campo de fecha y hora, esto ordenará los datos reales por el valor de fecha y hora. Consulte http://msdn.microsoft.com/en-us/library/aa933131(SQL.80).aspx para usar índices agrupados.

Esto hará que las búsquedas int sean más lentas, ya que serán relegadas a utilizar un índice no agrupado.

Answer 5

¿Podría ser que haya un índice para su columna int pero no para su columna de fecha y hora? Mire el plan de ejecución.

Answer 6

¿Ha agregado el campo DateTime al "índice" o a un índice exclusivo? ¿Está filtrando su selección por otro campo y el DateTime o solo este?

Debe tener un índice con todos los campos que está filtrando y preferiblemente en el mismo orden para optimizar el rendimiento.

Answer 7

en honor a la orden por parte del motor tiene dos alternativas:

• escanear las filas utilizando un índice que ofrece el orden solicitado
• ordenar las filas

primera opción es rápido, segundo es lento. El problema es que para ser utilizado, el índice tiene que ser un que cubra el índice. Lo que significa que contiene todas las columnas en la lista de proyección SELECT y todas las columnas utilizadas en las cláusulas WHERE (como mínimo). Si el índice no está cubriendo, el motor debería buscar el índice agrupado (es decir, la "tabla") para cada fila, a fin de recuperar los valores de las columnas necesarias. Esta búsqueda constante de valores es costosa, y hay un punto de inflexión en el que el motor (con razón) decidirá que es más eficiente escanear el índice agrupado y ordenar el resultado, ignorando de hecho su índice no agrupado. Para más detalles, vea The Tipping Point Query Answers.

en cuenta las tres preguntas siguientes:

SELECT dateColumn FROM table ORDER BY dateColumn 
SELECT * FROM table ORDER BY dateColumn 
SELECT someColumn FROM table ORDER BY dateColumn 

La primera de ellas se utilizará un índice no agrupado en dateColumn. Pero el segundo no usará un índice en dateColumn, probablemente elija un escaneo y clasifique en su lugar filas de 1M. Por otro lado, la tercera consulta se puede beneficiar de un índice en Table(dateColumn) INCLUDE (someColumn).

Este tema se cubre en su totalidad en MSDN, vea Index Design Basics, General Index Design Guidelines, Nonclustered Index Design Guidelines o How To: Optimize SQL Indexes.

En última instancia, la elección más importante de su diseño de tabla es el índice agrupado que utiliza. Casi siempre la clave principal (por lo general, una ID autoincrementada) se deja como índice agrupado, una decisión que beneficia solo ciertas cargas OLTP.

Y, por último, una pregunta bastante obvia: ¿Por qué en el mundo pediría 1 millón de filas? No puedes mostrarlos, ¿verdad? Explicar un poco más acerca de su caso de uso podría ayudarnos a encontrar una mejor respuesta para usted.