这是我使用的:

SELECT CAST(FLOOR(CAST(getdate() as FLOAT)) as DATETIME)

我想可能会有更好更优雅的方式。

要求:

  • 它必须尽可能快(铸造越少越好)。
  • 最终结果必须是datetime类型,而不是字符串。

===============>>#1 票数:112 已采纳

SQL Server 2008及更高版本

在SQL Server 2008及更高版本中,当然最快的方法是Convert(date, @date) 如有必要,可以将其datetime转换为datetimedatetime2

在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));
-- result: 2010-09-12 00:00:00.000 -- oops

这不是我们应该在我们的代码或在线示例中教人们的东西。

而且,它甚至不是最快的方式!

证明 - 性能测试

如果你想自己进行一些测试,看看不同的方法是如何叠加的,那么你需要这个安装脚本来进一步运行测试:

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;  -- 25,920,000 rows

请注意,这会在您的数据库中创建一个427.57 MB的表,并且需要15-30分钟才能运行。 如果您的数据库很小并且设置为10%增长,则需要的时间比首先大小足够大。

现在进行实际的性能测试脚本。 请注意,不会将行返回给客户端是有目的的,因为这在2600万行上非常昂贵并且会隐藏方法之间的性能差异。

表现结果

set statistics time on;
-- (All queries are the same on io: logical reads 54712)
GO
declare
    @dd date,
    @d datetime,
    @di int,
    @df float,
    @dv varchar(10);

-- Round trip back to datetime
select @d = CONVERT(date, Tm) from AllDay; -- CPU time = 21234 ms,  elapsed time = 22301 ms.
select @d = CAST(Tm - 0.50000004 AS int) from AllDay; -- CPU = 23031 ms, elapsed = 24091 ms.
select @d = DATEDIFF(DAY, 0, Tm) from AllDay; -- CPU = 23782 ms, elapsed = 24818 ms.
select @d = FLOOR(CAST(Tm as float)) from AllDay; -- CPU = 36891 ms, elapsed = 38414 ms.
select @d = CONVERT(VARCHAR(8), Tm, 112) from AllDay; -- CPU = 102984 ms, elapsed = 109897 ms.
select @d = CONVERT(CHAR(8), Tm, 112) from AllDay; -- CPU = 103390 ms,  elapsed = 108236 ms.
select @d = CONVERT(VARCHAR(10), Tm, 101) from AllDay; -- CPU = 123375 ms, elapsed = 135179 ms.

-- Only to another type but not back
select @dd = Tm from AllDay; -- CPU time = 19891 ms,  elapsed time = 20937 ms.
select @di = CAST(Tm - 0.50000004 AS int) from AllDay; -- CPU = 21453 ms, elapsed = 23079 ms.
select @di = DATEDIFF(DAY, 0, Tm) from AllDay; -- CPU = 23218 ms, elapsed = 24700 ms
select @df = FLOOR(CAST(Tm as float)) from AllDay; -- CPU = 29312 ms, elapsed = 31101 ms.
select @dv = CONVERT(VARCHAR(8), Tm, 112) from AllDay; -- CPU = 64016 ms, elapsed = 67815 ms.
select @dv = CONVERT(CHAR(8), Tm, 112) from AllDay; -- CPU = 64297 ms,  elapsed = 67987 ms.
select @dv = CONVERT(VARCHAR(10), Tm, 101) from AllDay; -- CPU = 65609 ms, elapsed = 68173 ms.
GO
set statistics time off;

一些漫步分析

关于此的一些注释。 首先,如果只是执行GROUP BY或比较,则无需转换回datetime 因此,除非您需要最终值用于显示目的,否则可以通过避免这种情况来节省一些CPU。 您甚至可以将GROUP转换为未转换的值,并仅将转换放在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转换几乎翻倍? 这揭示了用于查询中日期计算的CPU部分。 CPU使用的某些部分不涉及日期计算,在上述查询中,这似乎接近19875毫秒。 然后转换需要一些额外的金额,因此如果有两次转换,则该金额大约用完两次。

更多的检查发现,相对于Convert(, 112)Convert(, 101)查询有一些额外的CPU开销(因为它使用更长的varchar ?),因为第二个转换回date不花费多达初始转换为varchar ,但使用Convert(, 112)它更接近相同的20000 ms CPU基本成本。

以下是我用于上述分析的CPU时间计算:

     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时间的CPU时间。

  • single是单次转换为备用数据类型的CPU时间(具有删除时间部分的副作用的那种)。

  • base是计算从single中减去两个调用之间的差异: single - (round - single) 这是一个大概的假设,假设转换到该数据类型和从该数据类型和datetime的转换在任一方向上大致相同。 看起来这个假设并不完美但是接近因为这些值都接近20000毫秒,只有一个例外。

另一个有趣的事情是基本成本几乎等于单个Convert(date)方法(必须几乎为0成本,因为服务器可以在datetime数据的前四个字节中从内部提取整数日部分类型)。

结论

所以看起来是单向varchar转换方法需要大约1.8μs,单向DateDiff方法大约需要DateDiff 我基于最保守的“基本CPU”时间来测试18458 ms总共25,920,000行,因此23218 ms / 25920000 =0.18μs。 显而易见的10倍改进似乎很多,但坦率地说,直到你处理成千上万行(617k行= 1秒节省)时,它实际上相当小。

即使考虑到这种小的绝对改进,在我看来, DateAdd方法获胜也是因为它是性能和清晰度的最佳组合。 需要“幻数” 0.50000004的答案有一天会咬人(五个零或六个???),而且更难理解。

补充说明

当我得到一些时间我将要改变0.50000004'12:00:00.003'并看看它是如何做的。 它被转换为相同的datetime值,我发现它更容易记住。

对于那些感兴趣的人,上述测试是在服务器上运行的,其中@@ Version返回以下内容:

Microsoft SQL Server 2008(RTM) - 10.0.1600.22(Intel X86)2008年7月9日14:43:34版权所有(c)1988-2008 Microsoft Corporation在Windows NT 5.2上的标准版(Build 3790:Service Pack 2)

===============>>#2 票数:30

SQL Server 2008具有新的日期数据类型 ,这将此问题简化为:

SELECT CAST(CAST(GETDATE() AS date) AS datetime)

===============>>#3 票数:18

DATETIME计算中的 Itzik Ben-Gan ,第1部分 (SQL Server Magazine,2007年2月)显示了执行这种转换的三种方法(从最慢到最快 ;第二种和第三种方法之间的差异很小):

SELECT CAST(CONVERT(char(8), GETDATE(), 112) AS datetime)

SELECT DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0)

SELECT CAST(CAST(GETDATE() - 0.50000004 AS int) AS datetime)

你的技术(铸造浮动 )是由该杂志4月刊的读者提出的。 据他介绍,它具有与上述第二种技术相当的性能。

===============>>#4 票数:12

您的CAST - FLOOR - CAST似乎已经成为最佳方式,至少在MS SQL Server 2005上如此。

我见过的其他一些解决方案有一个字符串转换,比如Select Convert(varchar(11), getdate(),101) ,它慢了10倍。

===============>>#5 票数:4

请试试:

SELECT CONVERT(VARCHAR(10),[YOUR COLUMN NAME],105) [YOURTABLENAME]

===============>>#6 票数:1

SQL2005:我建议使用cast而不是dateadd。 例如,

select cast(DATEDIFF(DAY, 0, datetimefield) as datetime)

我的数据集平均速度比平均 10%左右

select DATEADD(DAY, DATEDIFF(DAY, 0, datetimefield), 0)

(并且铸造到smalldatetime仍然更快)

  ask by Nathan Bedford translate from so

未解决问题?本站智能推荐: