Devo ammettere che non avevo mai visto la conversione del galleggiante da pavimento mostrata da Matt prima. Ho dovuto testarlo.
Ho testato una selezione pura (che restituirà data e ora, e non è quello che vogliamo), la soluzione regnante qui (flottante), una comune "ingenua" menzionata qui (stringconvert) e quella menzionata qui che ero utilizzando (poiché pensavo fosse il più veloce).
Ho testato le query su un server di test MS SQL Server 2005 in esecuzione su un server Win 2003 SP2 con una CPU Xeon 3GHz in esecuzione su memoria massima (32 bit, quindi circa 3,5 Gb). È notte dove mi trovo, quindi la macchina è al minimo quasi senza carico. Ho tutto per me.
Ecco il registro del mio test eseguito selezionando da una grande tabella contenente timestamp che variano fino al livello del millisecondo. Questo particolare set di dati include date che vanno oltre 2,5 anni. La tabella stessa ha oltre 130 milioni di righe, ecco perché mi limito al primo milione.
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
Tempo di analisi e compilazione di SQL Server:tempo CPU =0 ms, tempo trascorso =1 ms.
(1000000 righe interessate) Tabella 'tblMeasureLogv2'. Conteggio scansioni 1, letture logiche 4752, letture fisiche 0, letture read-ahead 0, letture logiche lob 0, letture fisiche lob 0, letture read-ahead lob 0.
Tempi di esecuzione di SQL Server:tempo CPU =422 ms, tempo trascorso =33803 ms.
(1000000 righe interessate) Tabella 'tblMeasureLogv2'. Conteggio scansioni 1, letture logiche 4752, letture fisiche 0, letture read-ahead 0, letture logiche lob 0, letture fisiche lob 0, letture read-ahead lob 0.
Tempi di esecuzione di SQL Server:tempo CPU =625 ms, tempo trascorso =33545 ms.
(1000000 righe interessate) Tabella 'tblMeasureLogv2'. Conteggio scansioni 1, letture logiche 4752, letture fisiche 0, letture read-ahead 0, letture logiche lob 0, letture fisiche lob 0, letture read-ahead lob 0.
Tempi di esecuzione di SQL Server:tempo CPU =1953 ms, tempo trascorso =33843 ms.
(1000000 righe interessate) Tabella 'tblMeasureLogv2'. Conteggio scansioni 1, letture logiche 4752, letture fisiche 0, letture read-ahead 0, letture logiche lob 0, letture fisiche lob 0, letture read-ahead lob 0.
Tempi di esecuzione di SQL Server:tempo CPU =531 ms, tempo trascorso =33440 ms. Tempo di analisi e compilazione di SQL Server:tempo CPU =0 ms, tempo trascorso =1 ms.
Tempi di esecuzione di SQL Server:tempo CPU =0 ms, tempo trascorso =1 ms.
Cosa stiamo vedendo qui?
Concentriamoci sul tempo della CPU (stiamo guardando la conversione) e possiamo vedere che abbiamo i seguenti numeri:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Da questo mi sembra che DateAdd (almeno in questo caso particolare) sia leggermente più veloce del metodo floor-cast.
Prima di andare lì, ho eseguito questo test diverse volte, con l'ordine delle query modificato, risultati identici.
È qualcosa di strano sul mio server o cosa?
