Ich muss zugeben, dass ich die von Matt gezeigte Floor-Float-Umwandlung noch nie zuvor gesehen hatte. Das musste ich testen.
Ich habe eine reine Auswahl (die Datum und Uhrzeit zurückgibt und nicht das ist, was wir wollen), die hier herrschende Lösung (floor-float), eine hier erwähnte übliche 'naive' (stringconvert) und die hier erwähnte, die ich war, getestet verwenden (wie ich dachte, es war das schnellste).
Ich habe die Abfragen auf einem Testserver MS SQL Server 2005 getestet, der auf einem Win 2003 SP2-Server mit einer Xeon 3-GHz-CPU mit maximalem Speicher (32 Bit, also etwa 3,5 GB) ausgeführt wird. Es ist Nacht, wo ich bin, also läuft die Maschine fast ohne Last im Leerlauf. Ich habe alles für mich.
Hier ist das Protokoll meines Testlaufs, der aus einer großen Tabelle mit Zeitstempeln ausgewählt wurde, die bis auf die Millisekundenebene variieren. Dieser spezielle Datensatz enthält Daten über 2,5 Jahre. Die Tabelle selbst hat über 130 Millionen Zeilen, deshalb beschränke ich mich auf die oberste 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 Analyse- und Kompilierungszeit:CPU-Zeit =0 ms, verstrichene Zeit =1 ms.
(1000000 Zeile(n) betroffen) Tabelle „tblMeasureLogv2“. Anzahl der Scans 1, logische Lesevorgänge 4752, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.
SQL Server-Ausführungszeiten:CPU-Zeit =422 ms, verstrichene Zeit =33803 ms.
(1000000 Zeile(n) betroffen) Tabelle „tblMeasureLogv2“. Anzahl der Scans 1, logische Lesevorgänge 4752, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.
SQL Server-Ausführungszeiten:CPU-Zeit =625 ms, verstrichene Zeit =33545 ms.
(1000000 Zeile(n) betroffen) Tabelle „tblMeasureLogv2“. Anzahl der Scans 1, logische Lesevorgänge 4752, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.
SQL Server-Ausführungszeiten:CPU-Zeit =1953 ms, verstrichene Zeit =33843 ms.
(1000000 Zeile(n) betroffen) Tabelle „tblMeasureLogv2“. Anzahl der Scans 1, logische Lesevorgänge 4752, physische Lesevorgänge 0, Read-Ahead-Lesevorgänge 0, logische Lob-Reads 0, physische Lob-Reads 0, Lob-Read-Ahead-Reads 0.
SQL Server-Ausführungszeiten:CPU-Zeit =531 ms, verstrichene Zeit =33440 ms. SQL Server Analyse- und Kompilierungszeit:CPU-Zeit =0 ms, verstrichene Zeit =1 ms.
SQL Server-Ausführungszeiten:CPU-Zeit =0 ms, verstrichene Zeit =1 ms.
Was sehen wir hier?
Konzentrieren wir uns auf die CPU-Zeit (wir betrachten die Konvertierung), und wir können sehen, dass wir die folgenden Zahlen haben:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Daraus sieht es für mich so aus, als wäre DateAdd (zumindest in diesem speziellen Fall) etwas schneller als die Floorcast-Methode.
Bevor Sie dorthin gehen, habe ich diesen Test mehrere Male ausgeführt, wobei die Reihenfolge der Abfragen geändert wurde und die gleichen Ergebnisse erzielt wurden.
Ist das etwas Seltsames auf meinem Server, oder was?
