在这种情况下，仅限日期，我们将运行以下查询：

选择转换（VARCHAR（10），getdate（），111）；

在这种情况下，仅限日期，我们将运行以下查询：

选择转换（VARCHAR（10），getdate（），111）；

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转换无需考虑区域设置

DATEADD和DATEDIFF优于转换为varchar。两个查询都有相同的执行计划，但执行计划主要涉及数据访问策略，并不总是显示执行所有任务所需的CPU时间所涉及的隐含成本。如果两个查询都是针对具有数百万行的表运行的，则使用DateDiff的CPU时间可能接近Convert CPU时间的1/3！

要查看查询的执行计划，请执行以下操作：

set showplan_text on
GO 

DATEADD和DATEDIFF都将执行CONVERT_IMPLICIT。

虽然CONVERT解决方案对某些人来说更简单、更容易阅读，但速度较慢。不需要回滚到DateTime（这是由服务器隐式完成的）。之后，DateAdd也不需要使用DateDiff方法，因为整数结果也将隐式转换回DateTime。

从日期表选择转换（varchar，MyDate，101）

  |--Compute Scalar(DEFINE:([Expr1004]=CONVERT(varchar(30),[TEST].[dbo].[DatesTable].[MyDate],101)))
       |--Table Scan(OBJECT:([TEST].[dbo].[DatesTable]))

从日期表选择DATEADD（dd，0，DATEDIFF（dd，1，MyDate））

  |--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建议的FLOOR（）具有更接近DateDiff的性能，但不建议使用，因为将DateTime数据类型转换为float和back并不总是产生原始值。

记住：不要相信任何人。看看性能统计数据，然后自己测试！

测试结果时要小心。选择许多行到客户端将隐藏性能差异，因为通过网络发送行比执行计算所需的时间更长。因此，请确保所有行的工作都由服务器完成，但没有向客户端发送行集。

对于缓存优化何时影响查询，有些人似乎感到困惑。在同一批处理或单独批处理中运行两个查询对缓存没有影响。因此，您可以手动终止缓存，也可以简单地多次来回运行查询。对查询#2的任何优化也会影响任何后续查询，所以如果您愿意，请放弃执行#1。

这里是完整的测试脚本和性能结果，证明DateDiff比转换为varchar快得多。

哇，让我数一数你能做到这一点的方法。（无意双关）

为了以这种格式获得您想要的结果：

2008-09-22

这里有几个选项。

SELECT CAST(GETDATE() AS DATE) AS 'Date1'
SELECT Date2  = CONVERT(DATE, GETDATE())
SELECT CONVERT(DATE, GETDATE()) AS 'Date3'
SELECT CONVERT(CHAR(10), GETDATE(), 121) AS 'Date4'
SELECT CONVERT(CHAR(10), GETDATE(), 126) AS 'Date5'
SELECT CONVERT(CHAR(10), GETDATE(), 127) AS 'Date6'

所以，我建议你选择一个你满意的方法，并在所有的桌子上使用这种方法。

所有这些选项都以完全相同的格式返回日期。为什么SQL Server有这样的冗余？

我不知道，但他们知道。也许比我聪明的人可以回答这个问题。

希望这对某人有所帮助。

我赞成以下未提及的内容：

DATEFROMPARTS(DATEPART(yyyy, @mydatetime), DATEPART(mm, @mydatetime), DATEPART(dd, @mydatetime))

它也不关心本地或进行双重转换——尽管每个“datepart”可能都做数学运算。因此，它可能比datediff方法慢一点，但对我来说，它更清晰。尤其是当我想按年份和月份分组时（将日期设置为1）。