¿Por qué no es probable que el índice haga mucho si es DATETIME o DATETIME2 porque incluyen la porción de tiempo?

Question

Comentarios a question "How to decrease response time of a simple select query?" Tell:

• "? ¿Cuál es el tipo de datos en LaunchDate Un índice no es probable que hacer mucho si es DATETIME o DATETIME2 porque incluyen la porción de tiempo - OMG potros"

• "@OMG - ¿Por qué un índice agrupado en una columna DateTime no mejoraría el rendimiento? ¿La búsqueda es un escaneo de rango que permitiría una búsqueda de índice de rango rápido ya que todos los datos estarían en bloques secuenciales? Semi-related ... msdn.microsoft.com/en-us/library/ms177416.aspx - Calgary Coder "

• "Calgary Coder: DATETIME/2 incluye tiempo: un índice, agrupado o no agrupado, sería bueno para las fechas con tiempos duplicados pero no rangos. - OMG potros"

he creado una tabla de prueba con el índice agrupado en DATETIME columna de tipo LaunchDate y observar índice busca para consultas similares a citado en la anterior pregunta:

SELECT COUNT(primaryKeyColumn) 
FROM MarketPlan 
WHERE LaunchDate > @date 

en lugar de tabla o índice exploraciones .

¿por qué no un índice agrupado en una columna DateTime mejorar el rendimiento?
¿por qué no es índice de probabilidades de hacer mucho si es DATETIME o DATETIME2 porque incluyen la porción de tiempo?

Agradecería una secuencia de comandos que ilustrara que la indexación de la columna DATETIME no mejora el rendimiento.

Actualización: Además, ¿OMG implicar que índice en la columna Tipo de DATE sería de gran ayuda, pero no DATETIME y DATETIME2?

Answer 1

He leído la otra pregunta, ni idea de qué significa ponis OMG

3 puntos:

• No debería importar si un índice está agrupado o no agrupado:
• no importa si el tiempo está incluido también
• simplemente tiene que ser útil

SEEK o SCAN:

Basado en las estadísticas, si LaunchDate > @date medios, por ejemplo, el 90% de las filas, lo más probable es una exploración va a suceder. Si es bastante selectivo, entonces es más probable una búsqueda.

¡Independientemente de lo agrupado o no agrupado!

¿Qué índice?

una consulta como esto requeriría un índice en LaunchDate y primaryKeyColumn

SELECT COUNT(primaryKeyColumn) 
FROM MarketPlan 
WHERE LaunchDate > @date 

Ahora, cualquier índice no agrupado se refiere al índice agrupado que se supone que la PK de forma predeterminada. Así que primaryKeyColumn ya está implícitamente incluido.

superstición

Sin embargo, COUNT(primaryKeyColumn)is a superstition. Debido PK no permiten NULL, es equivalente a

SELECT COUNT(*) 
FROM MarketPlan 
WHERE LaunchDate > @date 

SELECT COUNT(1) 
FROM MarketPlan 
WHERE LaunchDate > @date 

Por lo que sólo necesita un índice en LaunchDate, ya sean agrupados o no agrupados

Answer 2

índice en una columna de fecha no será útil si el uso de la aplicación datetime que causa la conversión implícita del tipo de datos. Si observa el plan de ejecución, puede ver que hay una función interna aplicada a una columna. La solución es cambiar la columna de fecha a marca de tiempo (4) o ajustar la aplicación de cliente para usar fecha en lugar de fecha y hora.