SQL Server 2008 и выше
В SQL Server 2008 и выше, конечно, самый быстрый способ Convert(date, @date)
. При необходимости его можно вернуть в a datetime
или datetime2
.
Что действительно лучше всего в SQL Server 2005 и более ранних версиях?
Я видел противоречивые утверждения о том, как быстрее всего отсекать время от даты в SQL Server, и некоторые люди даже говорили, что они проводили тестирование, но мой опыт был другим. Так что давайте проведем еще несколько более строгих проверок и предоставим каждому сценарий, чтобы в случае ошибки люди могли меня исправить.
Преобразования с плавающей запятой неточны
Во-первых, я бы не стал конвертировать datetime
в float
, потому что он не конвертируется правильно. Вам может сойти с рук аккуратное удаление времени, но я думаю, что использовать его - плохая идея, потому что он неявно сообщает разработчикам, что это безопасная операция, а это не так . Взглянуть:
declare @d datetime;
set @d = '2010-09-12 00:00:00.003';
select Convert(datetime, Convert(float, @d));
Это не то, чему мы должны учить людей в нашем коде или в наших примерах в Интернете.
Кроме того, это даже не самый быстрый способ!
Доказательство - Тестирование производительности
Если вы хотите самостоятельно выполнить несколько тестов, чтобы увидеть, как на самом деле складываются разные методы, вам понадобится этот установочный скрипт, чтобы выполнить тесты дальше:
create table AllDay (Tm datetime NOT NULL CONSTRAINT PK_AllDay PRIMARY KEY CLUSTERED);
declare @d datetime;
set @d = DateDiff(Day, 0, GetDate());
insert AllDay select @d;
while @@ROWCOUNT != 0
insert AllDay
select * from (
select Tm =
DateAdd(ms, (select Max(DateDiff(ms, @d, Tm)) from AllDay) + 3, Tm)
from AllDay
) X
where Tm < DateAdd(Day, 1, @d);
exec sp_spaceused AllDay;
Обратите внимание, что это создает таблицу размером 427,57 МБ в вашей базе данных, и ее выполнение займет примерно 15–30 минут. Если ваша база данных мала и настроена на 10% -ный рост, это займет больше времени, чем если вы сначала установите достаточно большой размер.
Теперь о самом сценарии тестирования производительности. Обратите внимание, что целенаправленно не возвращать строки обратно клиенту, поскольку это безумно дорого для 26 миллионов строк и скроет различия в производительности между методами.
Результаты производительности
set statistics time on;
GO
declare
@dd date,
@d datetime,
@di int,
@df float,
@dv varchar(10);
select @d = CONVERT(date, Tm) from AllDay;
select @d = CAST(Tm - 0.50000004 AS int) from AllDay;
select @d = DATEDIFF(DAY, 0, Tm) from AllDay;
select @d = FLOOR(CAST(Tm as float)) from AllDay;
select @d = CONVERT(VARCHAR(8), Tm, 112) from AllDay;
select @d = CONVERT(CHAR(8), Tm, 112) from AllDay;
select @d = CONVERT(VARCHAR(10), Tm, 101) from AllDay;
select @dd = Tm from AllDay;
select @di = CAST(Tm - 0.50000004 AS int) from AllDay;
select @di = DATEDIFF(DAY, 0, Tm) from AllDay;
select @df = FLOOR(CAST(Tm as float)) from AllDay;
select @dv = CONVERT(VARCHAR(8), Tm, 112) from AllDay;
select @dv = CONVERT(CHAR(8), Tm, 112) from AllDay;
select @dv = CONVERT(VARCHAR(10), Tm, 101) from AllDay;
GO
set statistics time off;
Некоторый анализ азартных игр
Некоторые заметки по этому поводу. Прежде всего, если вы просто выполняете GROUP BY или сравнение, нет необходимости конвертировать обратно в datetime
. Таким образом, вы можете сэкономить немного ресурсов процессора, избегая этого, если вам не нужно окончательное значение для отображения. Вы даже можете GROUP BY по непреобразованному значению и поместить преобразование только в предложение SELECT:
select Convert(datetime, DateDiff(dd, 0, Tm))
from (select '2010-09-12 00:00:00.003') X (Tm)
group by DateDiff(dd, 0, Tm)
Кроме того, посмотрите, как числовые преобразования требуют немного больше времени для обратного преобразования datetime
, а varchar
преобразование почти удваивается? Это показывает, какая часть ЦП посвящена вычислению даты в запросах. Есть части использования ЦП, которые не связаны с вычислением даты, и в приведенных выше запросах это похоже на 19875 мс. Затем для преобразования требуется некоторая дополнительная сумма, поэтому при двух преобразованиях эта сумма расходуется примерно вдвое.
Более исследование показывает , что по сравнению Convert(, 112)
, то Convert(, 101)
запрос имеет некоторые дополнительные расходы на процессор (так как она использует больше varchar
?), Потому что второе преобразование обратно date
не стоит столько , сколько в качестве начального преобразования в varchar
, но Convert(, 112)
это ближе к тому же 20000 мс базовая стоимость процессора.
Вот те расчеты процессорного времени, которые я использовал для вышеупомянутого анализа:
method round single base
date 21324 19891 18458
int 23031 21453 19875
datediff 23782 23218 22654
float 36891 29312 21733
varchar-112 102984 64016 25048
varchar-101 123375 65609 7843
round - это время ЦП для возврата к datetime
.
single - это процессорное время для однократного преобразования в альтернативный тип данных (тот, который имеет побочный эффект удаления временной части).
база является вычисление вычитания из single
разности между двумя вызовами: single - (round - single)
. Это приблизительное значение, предполагающее преобразование в этот тип данных и из него, и datetime
оно примерно одинаково в обоих направлениях. Похоже, что это предположение не идеально, но близко, потому что все значения близки к 20000 мс за одним исключением.
Еще одна интересная вещь заключается в том, что базовая стоимость почти равна стоимости одного Convert(date)
метода (которая должна быть почти нулевой, поскольку сервер может внутренне извлекать целочисленную дневную часть прямо из первых четырех байтов типа datetime
данных).
Заключение
Таким образом, похоже, что varchar
метод однонаправленного преобразования занимает около 1,8 мкс, а метод однонаправленного преобразования - DateDiff
около 0,18 мкс. Я основываю это на самом консервативном «базовом времени ЦП» в моем тестировании, которое составляет 18458 мс для 25 920 000 строк, поэтому 23218 мс / 25920000 = 0,18 мкс. Кажущееся 10-кратное улучшение кажется большим, но, откровенно говоря, оно довольно мало, пока вы не имеете дело с сотнями тысяч строк (617 тыс. Строк = 1 секунда экономии).
Даже с учетом этого небольшого абсолютного улучшения, на мой взгляд, этот DateAdd
метод выигрывает, потому что это лучшее сочетание производительности и ясности. Ответ, который требует «магического числа», когда- 0.50000004
нибудь кого-нибудь укусит (пять нулей или шесть ???), плюс его труднее понять.
Дополнительные замечания
Когда я получаю какое - то время я собираюсь изменить , 0.50000004
чтобы '12:00:00.003'
увидеть , как он делает. Он преобразуется в то же datetime
значение, и мне его гораздо легче запомнить.
Для тех, кто заинтересован, приведенные выше тесты были запущены на сервере, где @@ Version возвращает следующее:
Microsoft SQL Server 2008 (RTM) - 10.0.1600.22 (Intel X86) 9 июля 2008 г. 14:43:34 Авторские права (c) 1988-2008 гг. Microsoft Corporation Standard Edition для Windows NT 5.2 (сборка 3790: пакет обновления 2)