DATETRUNC在SQL Server 2022中不可用，它未被包含在RTM及后续补丁中，执行会报错；官方文档无此函数，应使用DATEADD+DATEDIFF组合实现等效截断。
DATETRUNC 在 SQL Server 2022 中是否可用？
不能直接用。SQL Server 2022 不支持 DATETRUNC 函数——它最早出现在 SQL Server 2022 的某个 CTP 版本中，但最终被移除，正式 RTM（发布版）及后续 CU 补丁均未包含该函数。官方文档和系统函数列表里查不到 DATETRUNC，执行会报错：Invalid column name 'DATETRUNC' 或 Cannot find either column "dbo" or the user-defined function or aggregate "dbo.DATETRUNC"。
替代方案：用 DATEADD + DATEDIFF 实现等效截断
这是最常用、兼容性最好（从 SQL Server 2005 起就稳定支持）的写法，原理是“先算差值，再归零回加”。关键不是记住公式，而是理解每种粒度对应的偏移逻辑。
-
截断到日：
DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0) -
截断到小时：
DATEADD(hour, DATEDIFF(hour, 0, GETDATE()), 0) -
截断到分钟：
DATEADD(minute, DATEDIFF(minute, 0, GETDATE()), 0) -
截断到月：
DATEADD(month, DATEDIFF(month, 0, GETDATE()), 0) -
截断到年：
DATEADD(year, DATEDIFF(year, 0, GETDATE()), 0)
注意：0 是 SQL Server 中表示 1900-01-01 的整数基准，用它比用字符串 '19000101' 更高效，也避免隐式转换风险。
为什么不用 CONVERT + CAST 截断时间部分？
常见误区是用 CONVERT(date, GETDATE()) 得到日期，再转回 datetime ——这看似能“清空时间”，但有严重隐患：
- 结果类型变成
date（精度丢失），再转datetime会固定为当天 00:00:00.000，无法保留原始精度（比如原始是datetime2(7)） - 若字段是
datetime2，强制转date再转回会丢失纳秒级精度，且在计算窗口或索引覆盖场景下可能引发隐式转换警告 - 性能不如
DATEADD/DATEDIFF：后者全程在 datetime 类型内运算，无类型转换开销
用 EOMONTH 或其他函数能替代吗？
不能通用替代。EOMONTH 只解决“月末”这一种边界，而截断本质是“向下取整到指定粒度起点”。例如：
- 想把
2024-03-15 14:22:03.123截断到周一开始（周一为一周起点），EOMONTH完全无用 - SQL Server 2022 新增的
DATE_BUCKET可以做分桶，但它返回的是桶编号（整数），不是截断后的日期值；需配合DATEADD手动还原，反而更绕 - 真正接近
DATETRUNC语义的，仍是DATEADD + DATEDIFF组合，且已验证在 SQL Server 2022 中完全可用、无兼容性问题
别被版本号误导——SQL Server 2022 没有 DATETRUNC，但老办法更稳、更快、更可控。最容易忽略的是基准值选 0 而非字符串，以及对 datetime2 类型要保持类型一致，否则隐式转换会在执行计划里悄悄拖慢查询。
