Как вернуть только дату из типа данных SQL Server DateTime
Если вы склонны избегать обратной передачи сервера для проверки ввода, вы можете base64 закодировать свой скрытый ввод и, по крайней мере, сделать его более трудным для людей, чтобы вмешаться в него.
9 ответов
На SQL Server 2008 и выше, Вы должны CONVERT до настоящего времени:
SELECT CONVERT(date, getdate())
На более старых версиях, можно сделать следующее:
SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, @your_date))
, например
SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE()))
дает мне
2008-09-22 00:00:00.000
Профессионалы:
- Никакой
varchar<->datetimeпреобразования потребовали - Никакая потребность думать [приблизительно 1 110]
, Как предложено [1 112] Использование Michael
этот вариант: SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, getdate()))
select getdate()
SELECT DATEADD(hh, DATEDIFF(hh, 0, getdate()), 0)
SELECT DATEADD(hh, 0, DATEDIFF(hh, 0, getdate()))
SELECT DATEADD(dd, DATEDIFF(dd, 0, getdate()), 0)
SELECT DATEADD(dd, 0, DATEDIFF(dd, 0, getdate()))
SELECT DATEADD(mm, DATEDIFF(mm, 0, getdate()), 0)
SELECT DATEADD(mm, 0, DATEDIFF(mm, 0, getdate()))
SELECT DATEADD(yy, DATEDIFF(yy, 0, getdate()), 0)
SELECT DATEADD(yy, 0, DATEDIFF(yy, 0, getdate()))
Вывод:
2019-04-19 08:09:35.557
2019-04-19 08:00:00.000
4763-02-17 00:00:00.000
2019-04-19 00:00:00.000
2019-04-19 00:00:00.000
2019-04-01 00:00:00.000
1903-12-03 00:00:00.000
2019-01-01 00:00:00.000
1900-04-30 00:00:00.000
2008 SQLServer теперь имеет тип данных 'даты', который содержит только дату без компонента времени. Любой использующий SQLServer 2008 и вне может сделать следующее:
SELECT CONVERT(date, GETDATE())
DATEADD и DATEDIFF лучше, чем ПРЕОБРАЗОВАНИЕ в varchar. Оба запроса имеют тот же план выполнения, но планы выполнения являются, в первую очередь [приблизительно 1 116] данными стратегии доступа и не всегда показывают неявные затраты, включенные в процессорное время, потраченное для выполнения всех частей. Если оба запроса выполняются против таблицы с миллионами строк, процессорное время с помощью DateDiff может быть близко к 1/3-му из процессорного времени Преобразования!
Для наблюдения планов выполнения относительно запросов:
set showplan_text on
GO
И DATEADD и DATEDIFF выполнят CONVERT_IMPLICIT.
, Хотя решение для ПРЕОБРАЗОВАНИЯ более просто и легко для чтения для некоторых, это медленнее. Нет никакой потребности вспомнить дату и время (это неявно сделано сервером). Нет также никакой реальной потребности в методе DateDiff для DateAdd позже, поскольку целочисленный результат будет также неявно преобразован назад в дату и время.
<час>ИЗБРАННОЕ ПРЕОБРАЗОВАНИЕ (varchar, MyDate, 101) С <часа> DatesTable
|--Compute Scalar(DEFINE:([Expr1004]=CONVERT(varchar(30),[TEST].[dbo].[DatesTable].[MyDate],101)))
|--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))
ИЗБРАННЫЙ DATEADD (dd, 0, DATEDIFF (dd, 0, MyDate)) ОТ DatesTable
|--Compute Scalar(DEFINE:([Expr1004]=dateadd(day,(0),CONVERT_IMPLICIT(datetime,datediff(day,'1900-01-01 00:00:00.000',CONVERT_IMPLICIT(datetime,[TEST].[dbo].[DatesTable].[MyDate],0)),0))))
|--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))
Используя ПОЛ () как @digi предложенный имеет производительность ближе к DateDiff, но не рекомендуется, поскольку кастинг типа данных datetime, чтобы плавать и отступить не всегда приводит к исходному значению.
Помнят парней: не верьте никому. Посмотрите на статистику производительности и протестируйте ее сами!
Быть осторожным, когда Вы тестируете свои результаты. Выбор многих строк клиенту скроет различие в производительности becauses, занимает больше времени отправить строки по сети, чем это делает для выполнения вычислений. Поэтому удостоверьтесь, что работа для всех строк сделана сервером, но нет никакого набора строк, отправленного клиенту.
, кажется, существует беспорядок для некоторых людей о том, когда оптимизация кэша влияет на запросы. Выполнение двух запросов в том же пакете или в отдельных пакетах не имеет никакого эффекта на кэширование. Таким образом, можно или истечь кэш вручную или просто выполнить запросы назад и вперед многократно. Любая оптимизация для запроса № 2 также влияла бы на любые последующие запросы, поэтому вывела бы выполнение № 1, если Вам нравится.
Вот полный сценарий тестирования и результаты проверки производительности , которые доказывают, что DateDiff существенно быстрее, чем преобразование в varchar.
Попробуйте это:
SELECT CONVERT(VARCHAR(10),GETDATE(),111)
вышеупомянутый оператор преобразовывает Ваш текущий формат в YYYY/MM/DD, пошлите к эта ссылка выбрать свой предпочтительный формат.
SELECT CONVERT(datetime, CONVERT(varchar, GETDATE(), 101))
Можно использовать эти CONVERT функция для возврата только даты. См. ссылку (ссылки) ниже:
Управление Датой и временем в SQL Server 2000
, синтаксис для использования функции преобразования:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
Используя ПОЛ () - просто часть времени сокращения.
SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)
SELECT DATEADD(DD, DATEDIFF(DD, 0, GETDATE()), 0)
SELECT DATEADD(DAY, 0, DATEDIFF(DAY,0, GETDATE()))
SELECT CONVERT(DATETIME, CONVERT(VARCHAR(10), GETDATE(), 101))
Редактирование: первые два метода являются по существу тем же, и выполняют преобразование в varchar метод.
Если Вы хотите, чтобы дата показала 2008-09-22 00:00:00.000
затем, Вы можете вокруг нее с помощью
SELECT CONVERT(datetime, (ROUND(convert(float, getdate()-.5),0)))
, Это покажет дату в формате в вопросе