Je dois admettre que je n'avais jamais vu la conversion plancher-flotteur montrée par Matt auparavant. J'ai dû tester ça.
J'ai testé une sélection pure (qui renverra la date et l'heure, et ce n'est pas ce que nous voulons), la solution régnante ici (floor-float), une commune "naïve" mentionnée ici (stringconvert) et celle mentionnée ici que j'étais en utilisant (car je pensais que c'était le plus rapide).
J'ai testé les requêtes sur un serveur de test MS SQL Server 2005 exécuté sur un serveur Win 2003 SP2 avec un processeur Xeon 3 GHz fonctionnant sur la mémoire maximale (32 bits, soit environ 3,5 Go). Il fait nuit chez moi donc la machine tourne au ralenti presque à vide. J'ai tout pour moi.
Voici le journal de mon test en sélectionnant dans une grande table contenant des horodatages variant jusqu'au niveau de la milliseconde. Cet ensemble de données particulier comprend des dates allant de plus de 2,5 ans. Le tableau lui-même compte plus de 130 millions de lignes, c'est pourquoi je me limite au million supérieur.
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
Temps d'analyse et de compilation de SQL Server :temps CPU =0 ms, temps écoulé =1 ms.
(1000000 ligne(s) affectée(s)) Table 'tblMeasureLogv2'. Nombre de balayages 1, lectures logiques 4752, lectures physiques 0, lectures anticipées 0, lectures logiques lob 0, lectures physiques lob 0, lectures anticipées lob 0.
Temps d'exécution de SQL Server :temps CPU =422 ms, temps écoulé =33 803 ms.
(1000000 ligne(s) affectée(s)) Table 'tblMeasureLogv2'. Nombre de balayages 1, lectures logiques 4752, lectures physiques 0, lectures anticipées 0, lectures logiques lob 0, lectures physiques lob 0, lectures anticipées lob 0.
Temps d'exécution SQL Server :temps CPU =625 ms, temps écoulé =33 545 ms.
(1000000 ligne(s) affectée(s)) Table 'tblMeasureLogv2'. Nombre de balayages 1, lectures logiques 4752, lectures physiques 0, lectures anticipées 0, lectures logiques lob 0, lectures physiques lob 0, lectures anticipées lob 0.
Temps d'exécution de SQL Server :temps CPU =1 953 ms, temps écoulé =33 843 ms.
(1000000 ligne(s) affectée(s)) Table 'tblMeasureLogv2'. Nombre de balayages 1, lectures logiques 4752, lectures physiques 0, lectures anticipées 0, lectures logiques lob 0, lectures physiques lob 0, lectures anticipées lob 0.
Temps d'exécution SQL Server :temps CPU =531 ms, temps écoulé =33 440 ms. Temps d'analyse et de compilation de SQL Server :temps CPU =0 ms, temps écoulé =1 ms.
Temps d'exécution de SQL Server :temps CPU =0 ms, temps écoulé =1 ms.
Que voyons-nous ici ?
Concentrons-nous sur le temps CPU (nous examinons la conversion), et nous pouvons voir que nous avons les chiffres suivants :
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
À partir de là, il me semble que DateAdd (au moins dans ce cas particulier) est légèrement plus rapide que la méthode de diffusion au sol.
Avant de vous y rendre, j'ai exécuté ce test plusieurs fois, avec l'ordre des requêtes modifié, les résultats sont identiques.
Est-ce quelque chose d'étrange sur mon serveur, ou quoi ?
