Muszę przyznać, że nigdy wcześniej nie widziałem konwersji pływaka podłogowego pokazanego przez Matta. Musiałem to przetestować.
Przetestowałem czysty wybór (który zwróci datę i godzinę, a nie jest tym, czego chcemy), dominujące rozwiązanie tutaj (floor-float), wspólne „naiwne” wspomniane tutaj (stringconvert) i wspomniane tutaj, że byłem używając (jak myślałem, że był najszybszy).
Testowałem zapytania na serwerze testowym MS SQL Server 2005 działającym na serwerze Win 2003 SP2 z procesorem Xeon 3GHz działającym na maksymalnej pamięci (32 bity, czyli około 3,5 Gb). Tam, gdzie jestem, jest noc, więc maszyna pracuje na biegu jałowym prawie bez obciążenia. Mam to wszystko dla siebie.
Oto dziennik z mojego testu wybierającego z dużej tabeli zawierającej znaczniki czasu zmieniające się do poziomu milisekund. Ten konkretny zbiór danych obejmuje daty sięgające ponad 2,5 roku. Sama tabela ma ponad 130 milionów wierszy, dlatego ograniczam się do pierwszego miliona.
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
Czas parsowania i kompilacji SQL Server:czas procesora =0 ms, czas, który upłynął =1 ms.
(1000000 wierszy, których dotyczy problem) Tabela „tblMeasureLogv2”. Liczba skanów 1, odczyty logiczne 4752, odczyty fizyczne 0, odczyty z wyprzedzeniem 0, odczyty logiczne modułu 0, odczyty fizyczne modułu 0, odczyty modułu z wyprzedzeniem 0.
Czasy wykonywania programu SQL Server:czas procesora =422 ms, czas, który upłynął =33803 ms.
(1000000 wierszy, których dotyczy problem) Tabela „tblMeasureLogv2”. Liczba skanów 1, odczyty logiczne 4752, odczyty fizyczne 0, odczyty z wyprzedzeniem 0, odczyty logiczne modułu 0, odczyty fizyczne modułu 0, odczyty modułu z wyprzedzeniem 0.
Czasy wykonywania programu SQL Server:czas procesora =625 ms, czas, który upłynął =33545 ms.
(1000000 wierszy, których dotyczy problem) Tabela „tblMeasureLogv2”. Liczba skanów 1, odczyty logiczne 4752, odczyty fizyczne 0, odczyty z wyprzedzeniem 0, odczyty logiczne modułu 0, odczyty fizyczne modułu 0, odczyty modułu z wyprzedzeniem 0.
Czasy wykonywania programu SQL Server:czas procesora =1953 ms, czas, który upłynął =33843 ms.
(1000000 wierszy, których dotyczy problem) Tabela „tblMeasureLogv2”. Liczba skanów 1, odczyty logiczne 4752, odczyty fizyczne 0, odczyty z wyprzedzeniem 0, odczyty logiczne modułu 0, odczyty fizyczne modułu 0, odczyty modułu z wyprzedzeniem 0.
Czasy wykonania programu SQL Server:czas procesora =531 ms, czas, który upłynął =33440 ms. Czas parsowania i kompilacji SQL Server:czas procesora =0 ms, czas, który upłynął =1 ms.
Czasy wykonania serwera SQL:czas procesora =0 ms, czas, który upłynął =1 ms.
Co tu widzimy?
Skupmy się na czasie procesora (patrzymy na konwersję) i widzimy, że mamy następujące liczby:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Z tego wygląda na to, że DateAdd (przynajmniej w tym konkretnym przypadku) jest nieco szybszy niż metoda odlewania podłogi.
Zanim tam pójdziesz, przeprowadziłem ten test kilka razy, ze zmienioną kolejnością zapytań, z takimi samymi wynikami.
Czy to coś dziwnego na moim serwerze, czy co?
