SQL DATETRUNC函数截断日期时间用法

先扔个核心结论：DATETRUNC 是 SQL Server 2022 引入的原生日期截断函数，支持 year、quarter、month、day、hour、minute 等常见 datepart，行为严谨——不四舍五入、不隐式类型转换，语法简单：DATETRUNC(datepart, date)，第一个参数是关键字，不是字符串变量。但注意，它只在 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 更简洁、语义更清晰，而且能正确处理时区和边界——比如月末、夏令时切换这些容易翻车的场景。

• 语法：DATETRUNC(, )，第一个参数必须是字符串字面量（不能是变量或表达式），比如 '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' 也不支持——这是常见的拼写错误来源，很多人上来就写 'week' 然后报错。

旧版 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 < '2024-02-01' 差很多。
• 跨时区场景下，DATETRUNC 对 datetimeoffset 输入按本地偏移截断，不是 UTC。如果业务要求统一按 UTC 归组，得先 SWITCHOFFSET 再截断。

真正麻烦的不是语法本身，而是确认你连接的数据库版本是否真支持它——很多人复制了 SQL Server 2022 的例子，却在 SQL Server 2019 实例上执行失败，连错误提示都看不出缺的是函数还是拼写。查版本最稳的方式是运行 SELECT @@VERSION，别信文档页眉写的“适用于 SQL Server”。