sql server 2022+才支持datetrunc，旧版本需用dateadd+datediff组合实现时间截断；按分钟/小时归位应避免convert字符串方式，推荐cte或计算列提升性能与可维护性。
SQL Server 2022+ 才有 DATETRUNC，旧版本会报错
直接执行 DATETRUNC('minute', GETDATE()) 却提示“‘DATETRUNC’ 不是可识别的内置函数名”，大概率是你用的是 SQL Server 2019 或更早版本。这个函数是 2022 才正式引入的，2019 CU17+ 和 2017 CU30+ 虽然有预览版，但默认禁用且行为不稳定，不建议生产环境启用。
确认版本的方法是运行：SELECT @@VERSION。如果版本低于 2022，就得换方案——别硬改兼容级别或打补丁，归位逻辑本身很简单，用 DATEADD + DATEDIFF 组合完全能等效实现。
按分钟归位：截断到最近整分钟（非四舍五入）
监控数据时间戳常带秒和毫秒，比如 '2024-06-15 14:23:47.123'，要归为 '2024-06-15 14:23:00.000'，本质是“去掉秒及以下部分”。DATETRUNC('minute', ...) 直观，但等效写法更通用：
- 用
DATEDIFF(minute, 0, dt)算出从基准时间（1900-01-01）到目标时间的总分钟数 - 再用
DATEADD(minute, ..., 0)把这个分钟数加回去，自然丢弃秒级以下精度
示例：
SELECT DATEADD(minute, DATEDIFF(minute, 0, '2024-06-15 14:23:47.123'), 0) -- 返回：2024-06-15 14:23:00.000
注意：这不是四舍五入，是向下取整（floor），'14:23:59.999' 也会归到 14:23:00；如果真需要四舍五入到最近分钟，得额外加 30 秒再截断。
按小时归位：避免用 CONVERT 截字符串这种脆弱方式
有人用 CONVERT(char(13), dt, 120) 得到 '2024-06-15 14' 再拼接，看似快，但隐患多：
- 返回类型是字符串，后续无法直接参与日期计算或索引查找
- 时区或语言设置变化可能让格式失效（比如
SET LANGUAGE French后120格式可能异常） - 隐式转换容易触发全表扫描，尤其在
WHERE或GROUP BY中
正确做法仍是 DATEADD + DATEDIFF：
SELECT DATEADD(hour, DATEDIFF(hour, 0, '2024-06-15 14:23:47.123'), 0) -- 返回：2024-06-15 14:00:00.000
这个结果是真正的 datetime2 类型，能走索引、可计算、无区域依赖。
GROUP BY 场景下性能与可读性平衡
监控数据常需按分钟/小时聚合，比如查每分钟平均 CPU 使用率。这时归位表达式会重复出现：
GROUP BY DATEADD(minute, DATEDIFF(minute, 0, event_time), 0)
直接写两遍（SELECT 和 GROUP BY）易出错，也难维护。推荐用派生表或 CTE 提前计算：
WITH grouped AS (
SELECT
DATEADD(minute, DATEDIFF(minute, 0, event_time), 0) AS minute_slot,
cpu_usage
FROM metrics
)
SELECT minute_slot, AVG(cpu_usage)
FROM grouped
GROUP BY minute_slot;
CTE 不仅提升可读性，SQL Server 优化器通常也能正确复用计算结果。如果数据量极大且该字段高频使用，考虑在表上加计算列并建索引——但注意计算列必须是确定性的，DATEADD(DATEDIFF(...)) 满足条件，而 GETDATE() 这类就不行。
归位本身不难，难的是选对时机：是入库前清洗？查询时动态计算？还是建汇总表定时跑？这取决于监控数据的实时性要求和查询频次，别一上来就堆索引或物化视图。
