Трябва да призная, че не бях виждал преди това преобразуването на подово плаване, показано от Мат. Трябваше да тествам това.
Тествах чист избор (който ще върне дата и час и не е това, което искаме), господстващото решение тук (floor-float), обикновено „наивно“, споменато тук (stringconvert) и споменатото тук, че бях използвайки (както мислех, че е най-бързият).
Тествах заявките на тестов сървър MS SQL Server 2005, работещ на Win 2003 SP2 сървър с Xeon 3GHz CPU, работещ на максимална памет (32 бита, така че това е около 3,5 Gb). Аз съм нощ, така че машината работи на празен ход почти без натоварване. Имам всичко за себе си.
Ето дневника от моето тестово изпълнение, избирайки от голяма таблица, съдържаща времеви печати, вариращи до ниво милисекунда. Този конкретен набор от данни включва дати, вариращи над 2,5 години. Самата таблица има над 130 милиона реда, така че затова се ограничавам до най-добрите милиони.
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:CPU време =0 ms, изминало време =1 ms.
(засегнати 1000000 реда(а)) Таблица „tblMeasureLogv2“. Брой на сканиране 1, логически четения 4752, физически четения 0, четене напред 0, логически четения на лоб 0, физически четения на лоб 0, четене напред за четене 0.
Време за изпълнение на SQL Server:CPU време =422 ms, изминало време =33803 ms.
(засегнати 1000000 реда(а)) Таблица „tblMeasureLogv2“. Брой на сканиране 1, логически четения 4752, физически четения 0, четене напред 0, логически четения на лоб 0, физически четения на лоб 0, четене напред за четене 0.
Времена за изпълнение на SQL Server:CPU време =625 ms, изминало време =33545 ms.
(засегнати 1000000 реда(а)) Таблица „tblMeasureLogv2“. Брой на сканиране 1, логически четения 4752, физически четения 0, четене напред 0, логически четения на лоб 0, физически четения на лоб 0, четене напред за четене 0.
Времена за изпълнение на SQL Server:CPU време =1953 ms, изминало време =33843 ms.
(засегнати 1000000 реда(а)) Таблица „tblMeasureLogv2“. Брой на сканиране 1, логически четения 4752, физически четения 0, четене напред 0, логически четения на лоб 0, физически четения на лоб 0, четене напред за четене 0.
Време за изпълнение на SQL Server:CPU време =531 ms, изминало време =33440 ms. Време за анализиране и компилиране на SQL Server:CPU време =0 ms, изминало време =1 ms.
Време за изпълнение на SQL Server:CPU време =0 ms, изминало време =1 ms.
Какво виждаме тук?
Нека се съсредоточим върху времето на процесора (гледаме преобразуване) и можем да видим, че имаме следните числа:
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
Оттук ми се струва, че DateAdd (поне в този конкретен случай) е малко по-бърз от метода на пода.
Преди да отидете там, проведох този тест няколко пъти, с променен ред на заявките, същите резултати.
Това нещо странно ли е на моя сървър или какво?
