临摹微笑
DATEADD和DATEDIFF比转换为varchar更好。这两个查询都有相同的执行计划,但是执行计划主要是关于数据访问策略,并且不总是显示执行所有部分所需的CPU时间所涉及的隐含成本。如果两个查询都针对数百万行的表运行,则使用DateDiff的CPU时间可以接近转换CPU时间的三分之一!要查看查询的执行计划:set showplan_text onGODATEADD和DATEDIFF都将执行转换_隐式。虽然对某些人来说,转换解决方案更简单、更容易阅读,但它是慢点。不需要将数据转换为DateTime(这是服务器隐式完成的)。之后,DateDiff方法对于DateAdd也没有真正的需求,因为整数结果也将被隐式转换回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,0,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所建议的那样,使用place()具有更接近DateDiff的性能,但不建议将Datetime数据类型转换为浮动和返回,但并不总是产生原始值。记住伙计们:不要相信任何人。查看性能统计数据,并自己测试它!在测试结果时要小心。选择多个行将隐藏性能差异,因为通过网络发送行要比执行计算所用的时间要长。因此,请确保所有行的工作都由服务器完成,但没有发送到客户端的行集。对于某些人来说,缓存优化何时影响查询似乎有些混乱。在同一批或在不同批处理中运行两个查询对缓存没有影响。因此,您可以手动终止缓存,也可以简单地多次来回运行查询。对查询#2的任何优化也会影响后续的查询,因此如果您愿意,可以抛出执行#1。这是完整测试脚本和性能结果这证明DateDiff比转换为varchar要快得多。