Ik moet toegeven dat ik de door Matt getoonde floor-float-conversie nog niet eerder had gezien. Ik moest dit uittesten.
Ik testte een pure select (die datum en tijd zal retourneren, en is niet wat we willen), de heersende oplossing hier (floor-float), een veel voorkomende 'naïeve' hier genoemde (stringconvert) en degene die hier wordt genoemd dat ik was gebruiken (omdat ik dacht dat het de snelste was).
Ik heb de queries getest op een testserver MS SQL Server 2005 draaiend op een Win 2003 SP2 Server met een Xeon 3GHz CPU op max geheugen (32 bit, dus dat is ongeveer 3,5 Gb). Het is nacht waar ik ben, dus de machine draait stationair en bijna onbelast. Ik heb het helemaal voor mezelf.
Hier is het logboek van mijn testrun die ik selecteerde uit een grote tabel met tijdstempels die variëren tot op millisecondenniveau. Deze specifieke dataset bevat data van meer dan 2,5 jaar. De tabel zelf heeft meer dan 130 miljoen rijen, daarom beperk ik me tot de top miljoen.
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 parseer- en compileertijd:CPU-tijd =0 ms, verstreken tijd =1 ms.
(1000000 rij(en) aangetast) Tabel 'tblMeasureLogv2'. Scantelling 1, logische leest 4752, fysieke leest 0, read-ahead leest 0, lob logische leest 0, lob fysieke leest 0, lob read-ahead leest 0.
Uitvoeringstijden SQL Server:CPU-tijd =422 ms, verstreken tijd =33803 ms.
(1000000 rij(en) aangetast) Tabel 'tblMeasureLogv2'. Scantelling 1, logische leest 4752, fysieke leest 0, read-ahead leest 0, lob logische leest 0, lob fysieke leest 0, lob read-ahead leest 0.
Uitvoeringstijden SQL Server:CPU-tijd =625 ms, verstreken tijd =33545 ms.
(1000000 rij(en) aangetast) Tabel 'tblMeasureLogv2'. Scantelling 1, logische leest 4752, fysieke leest 0, read-ahead leest 0, lob logische leest 0, lob fysieke leest 0, lob read-ahead leest 0.
Uitvoeringstijden SQL Server:CPU-tijd =1953 ms, verstreken tijd =33843 ms.
(1000000 rij(en) aangetast) Tabel 'tblMeasureLogv2'. Scantelling 1, logische leest 4752, fysieke leest 0, read-ahead leest 0, lob logische leest 0, lob fysieke leest 0, lob read-ahead leest 0.
Uitvoeringstijden SQL Server:CPU-tijd =531 ms, verstreken tijd =33440 ms. SQL Server parseer- en compileertijd:CPU-tijd =0 ms, verstreken tijd =1 ms.
Uitvoeringstijden SQL Server:CPU-tijd =0 ms, verstreken tijd =1 ms.
Wat zien we hier?
Laten we ons concentreren op de CPU-tijd (we kijken naar conversie) en we kunnen zien dat we de volgende cijfers hebben:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Hieruit blijkt dat de DateAdd (althans in dit specifieke geval) iets sneller is dan de methode voor het gieten op de vloer.
Voordat je daarheen gaat, heb ik deze test verschillende keren uitgevoerd, waarbij de volgorde van de zoekopdrachten is gewijzigd, dezelfde resultaten.
Is dit iets vreemds op mijn server, of wat?