Jeg må indrømme, at jeg ikke havde set gulv-float-konverteringen vist af Matt før. Jeg var nødt til at teste det her.
Jeg testede en ren udvælgelse (som vil returnere dato og klokkeslæt, og som ikke er det, vi ønsker), den herskende løsning her (floor-float), en almindelig 'naiv' nævnt her (stringconvert) og den nævnte her, som jeg var bruger (som jeg troede, det var den hurtigste).
Jeg testede forespørgslerne på en test-server MS SQL Server 2005, der kører på en Win 2003 SP2-server med en Xeon 3GHz CPU, der kører på maksimal hukommelse (32 bit, så det er omkring 3,5 Gb). Det er nat, hvor jeg er, så maskinen kører i tomgang næsten uden belastning. Jeg har det hele for mig selv.
Her er loggen fra min testkørsel, der vælger fra en stor tabel, der indeholder tidsstempler, der varierer ned til millisekundniveau. Dette særlige datasæt indeholder datoer, der strækker sig over 2,5 år. Selve tabellen har over 130 millioner rækker, så derfor begrænser jeg mig til den øverste million.
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
SQL Server-parse og kompileringstid:CPU-tid =0 ms, forløbet tid =1 ms.
(1000000 række(r) påvirket) Tabel 'tblMeasureLogv2'. Scanningsantal 1, logisk læser 4752, fysisk læser 0, read-ahead læser 0, lob logisk læser 0, lob fysisk læser 0, lob read-ahead læser 0.
SQL Server-udførelsestider:CPU-tid =422 ms, forløbet tid =33803 ms.
(1000000 række(r) påvirket) Tabel 'tblMeasureLogv2'. Scanningsantal 1, logisk læser 4752, fysisk læser 0, read-ahead læser 0, lob logisk læser 0, lob fysisk læser 0, lob read-ahead læser 0.
SQL Server-udførelsestider:CPU-tid =625 ms, forløbet tid =33545 ms.
(1000000 række(r) påvirket) Tabel 'tblMeasureLogv2'. Scanningsantal 1, logisk læser 4752, fysisk læser 0, read-ahead læser 0, lob logisk læser 0, lob fysisk læser 0, lob read-ahead læser 0.
SQL Server-udførelsestider:CPU-tid =1953 ms, forløbet tid =33843 ms.
(1000000 række(r) påvirket) Tabel 'tblMeasureLogv2'. Scanningsantal 1, logisk læser 4752, fysisk læser 0, read-ahead læser 0, lob logisk læser 0, lob fysisk læser 0, lob read-ahead læser 0.
SQL Server-udførelsestider:CPU-tid =531 ms, forløbet tid =33440 ms. SQL Server-parse og kompileringstid:CPU-tid =0 ms, forløbet tid =1 ms.
SQL Server-udførelsestider:CPU-tid =0 ms, forløbet tid =1 ms.
Hvad ser vi her?
Lad os fokusere på CPU-tiden (vi kigger på konvertering), og vi kan se, at vi har følgende tal:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Ud fra dette ser det ud til, at DateAdd (i hvert fald i dette særlige tilfælde) er lidt hurtigere end gulvstøbningsmetoden.
Før du tager dertil, kørte jeg denne test flere gange, med rækkefølgen af forespørgslerne ændret, samme resultater.
Er dette noget mærkeligt på min server, eller hvad?