鉴于以下组件
DECLARE @D DATE = '2013-10-13'
DECLARE @T TIME(7) = '23:59:59.9999999'
将它们结合起来以产生DATETIME2(7)具有价值的结果的最佳方法是'2013-10-13 23:59:59.9999999'什么？
有些东西不工作，如下表所示。
SELECT @D + @T
操作数数据类型日期对加法运算符无效。
SELECT CAST(@D AS DATETIME2(7)) + @T
操作数数据类型 datetime2 对加法运算符无效。
SELECT DATEADD(NANOSECOND,DATEDIFF(NANOSECOND,CAST('00:00:00.0000000' AS TIME),@T),@D)
datediff 函数导致溢出。分隔两个日期/时间实例的日期部分数量太大。尝试将 datediff 与不太精确的日期部分一起使用。
* 可以在 Azure SQL 数据库和 SQL Server 2016 中避免溢出，使用DATEDIFF_BIG.
SELECT CAST(@D AS DATETIME) + @T
数据类型 datetime 和 time 在 add 运算符中不兼容。
SELECT CAST(@D AS DATETIME) + CAST(@T AS DATETIME)
返回结果但失去精度
2013-10-13 23:59:59.997
在 SQL Server 2008中添加了日期数据类型。
将datetime列转换date为sargable并且可以在datetime列上使用索引。
select *
from T
where cast(DateTimeCol as date) = '20130101';
您拥有的另一个选择是改用范围。
select *
from T
where DateTimeCol >= '20130101' and
DateTimeCol < '20130102'
这些查询是同样好还是应该优先于另一个？
我看到 sql join 内部函数总是在三个基本操作中的一些操作上运行：嵌套循环 join、merge join和hash join。
从互联网上的多篇文章中，我看到 SQL 转换据说能够严重影响性能，而且几乎总是因为它禁用了索引使用。
但对我来说，它看起来总是可以避免的：铸造可以禁用合并连接的使用（并从索引使用中获得合并的好处）但是散列连接，据说通常比合并更快，仍然可以以相同的方式使用（看起来我）。无论在散列连接（构建探针）转换的哪个阶段应用，所有必须额外完成的工作是在散列之前对所转换的列进行转换。
无论如何，散列连接通过第一个表的每一行一次，与第二个表相同。因此，从我的角度来看，应用于散列连接的连接列的转换对性能没有影响，但对转换操作本身没有影响。互联网上的人说因为不能使用索引，所以选角会严重影响性能？
我上面的想法有问题吗？谢谢你的时间