DATETRUNC是SQL Server 2022+原生日期截断函数，支持year、quarter、month、day、hour、minute等datepart，不四舍五入、不隐式类型转换，语法为DATETRUNC(datepart, date)，首参数为关键字非字符串。
DATETRUNC 不是标准 SQL 函数，它只在 Microsoft SQL Server 2022+ 和 Azure SQL Database 中原生支持。如果你用的是 PostgreSQL、MySQL 或旧版 SQL Server（如 2019 及更早），直接写 DATETRUNC 会报错：Invalid column name 'DATETRUNC' 或 Incorrect syntax near 'DATETRUNC'。
SQL Server 2022+ 中 DATETRUNC 的正确用法
它比手动 DATEADD+DATEDIFF 组合更简洁、语义更清晰，且能正确处理时区和边界（比如月末、夏令时切换）。
- 语法是
DATETRUNC(<datepart>, <date>)，第一个参数必须是字符串字面量（不能是变量或表达式），如'month'、'hour'、'iso_week' - 支持的
datepart包括：'year'、'quarter'、'month'、'day'、'hour'、'minute'、'second'、'millisecond'、'microsecond'、'nanosecond'、'iso_week' - 示例：把
'2024-03-15 14:47:22.123'截断到天 ——DATETRUNC('day', '2024-03-15 14:47:22.123')返回'2024-03-15 00:00:00.000' - 注意：截断到
'week'无效，必须用'iso_week'；截断到'weekday'也不支持 —— 这些是常见拼写错误来源
旧版 SQL Server 或其他数据库如何替代 DATETRUNC
没有 DATETRUNC 时，核心思路是“先归零再加回”，但不同数据库写法差异大：
- SQL Server 2016–2019：用
DATEFROMPARTS+YEAR/MONTH等提取，或经典组合DATEADD(dd, DATEDIFF(dd, 0, @dt), 0)（截断到日） - PostgreSQL：用
DATE_TRUNC('day', my_timestamp)—— 注意函数名是小写date_trunc，且第一个参数是字符串，和 SQL Server 的DATETRUNC行为一致但大小写敏感 - MySQL：没有内置等价函数，得靠
DATE()（仅日期）、DATE_FORMAT(dt, '%Y-%m-%d 00:00:00')（手动拼），或STR_TO_DATE(DATE_FORMAT(dt, '%Y-%m-%d'), '%Y-%m-%d') - BigQuery：用
TRUNC(dt, DAY)，单位是大写标识符（DAY、HOUR），不是字符串
为什么 DATETRUNC 在 GROUP BY 中容易出错？
看起来方便，但实际踩坑多：
- 如果字段是
datetime2(7)类型，DATETRUNC('day', dt)返回仍是datetime2(7)，但值被归零 —— 这没问题；但若字段是smalldatetime，截断后精度丢失（秒被四舍五入），导致分组结果意外合并 - 在 WHERE 中用
DATETRUNC('month', order_date) = '2024-01-01'无法走索引（除非建了计算列索引），性能比order_date >= '2024-01-01' AND order_date 差很多 - 跨时区场景下，
DATETRUNC对datetimeoffset输入按本地偏移截断，不是 UTC —— 如果业务要求统一按 UTC 归组，得先SWITCHOFFSET再截断
真正麻烦的不是语法，而是确认你连接的数据库版本是否真支持它 —— 很多人复制了 SQL Server 2022 的例子，却在 SQL Server 2019 实例上执行失败，连错误提示都看不出缺的是函数还是拼写。查版本最稳的方式是运行 SELECT @@VERSION，别信文档页眉写的“适用于 SQL Server”。
