Debo admitir que no había visto la conversión piso-flotante mostrada por Matt antes. Tenía que probar esto.
Probé una selección pura (que devolverá la fecha y la hora, y no es lo que queremos), la solución reinante aquí (flotante de piso), una 'ingenua' común mencionada aquí (stringconvert) y la mencionada aquí que estaba usando (como pensé que era el más rápido).
Probé las consultas en un servidor de prueba MS SQL Server 2005 que se ejecuta en un servidor Win 2003 SP2 con una CPU Xeon de 3 GHz que se ejecuta en la memoria máxima (32 bits, por lo que son aproximadamente 3,5 Gb). Es de noche donde estoy, por lo que la máquina funciona al ralentí casi sin carga. Lo tengo todo para mí.
Aquí está el registro de mi ejecución de prueba seleccionado de una tabla grande que contiene marcas de tiempo que varían hasta el nivel de milisegundos. Este conjunto de datos en particular incluye fechas que van más de 2,5 años. La tabla en sí tiene más de 130 millones de filas, por eso me limito al millón superior.
SELECT TOP 1000000 CRETS FROM tblMeasureLogv2
SELECT TOP 1000000 CAST(FLOOR(CAST(CRETS AS FLOAT)) AS DATETIME) FROM tblMeasureLogv2
SELECT TOP 1000000 CONVERT(DATETIME, CONVERT(VARCHAR(10), CRETS, 120) , 120) FROM tblMeasureLogv2
SELECT TOP 1000000 DATEADD(DAY, DATEDIFF(DAY, 0, CRETS), 0) FROM tblMeasureLogv2
Tiempo de análisis y compilación de SQL Server:tiempo de CPU =0 ms, tiempo transcurrido =1 ms.
(1000000 filas afectadas) Tabla 'tblMeasureLogv2'. Recuento de escaneo 1, lecturas lógicas 4752, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.
Tiempos de ejecución de SQL Server:tiempo de CPU =422 ms, tiempo transcurrido =33803 ms.
(1000000 filas afectadas) Tabla 'tblMeasureLogv2'. Recuento de escaneo 1, lecturas lógicas 4752, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.
Tiempos de ejecución de SQL Server:tiempo de CPU =625 ms, tiempo transcurrido =33545 ms.
(1000000 filas afectadas) Tabla 'tblMeasureLogv2'. Recuento de escaneo 1, lecturas lógicas 4752, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.
Tiempos de ejecución de SQL Server:tiempo de CPU =1953 ms, tiempo transcurrido =33843 ms.
(1000000 filas afectadas) Tabla 'tblMeasureLogv2'. Recuento de escaneo 1, lecturas lógicas 4752, lecturas físicas 0, lecturas anticipadas 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas anticipadas lob 0.
Tiempos de ejecución de SQL Server:tiempo de CPU =531 ms, tiempo transcurrido =33440 ms. Tiempo de análisis y compilación de SQL Server:tiempo de CPU =0 ms, tiempo transcurrido =1 ms.
Tiempos de ejecución de SQL Server:tiempo de CPU =0 ms, tiempo transcurrido =1 ms.
¿Qué estamos viendo aquí?
Centrémonos en el tiempo de CPU (estamos viendo la conversión), y podemos ver que tenemos los siguientes números:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
A partir de esto, me parece que DateAdd (al menos en este caso particular) es un poco más rápido que el método Floor-cast.
Antes de ir allí, realicé esta prueba varias veces, con el orden de las consultas cambiado, los mismos resultados.
¿Es esto algo extraño en mi servidor, o qué?
