datetrunc需谨慎使用：group by必须与select中表达式完全一致；where中应避免对字段套用datetrunc而改用范围查询；注意输入类型精度继承，慎用嵌套函数或强行替换简单逻辑。
DATETRUNC 能直接替代过去一堆 DATEADD/DATEDIFF 套娃，但用错地方反而让查询变慢、分组错乱——关键不是“能不能用”，而是“在哪用、怎么写”。
GROUP BY 必须和 SELECT 中的 DATETRUNC 表达式完全一致
常见错误是 SELECT 里写 DATETRUNC(month, order_date)，GROUP BY 却只写 order_date 或 YEAR(order_date), MONTH(order_date)，SQL Server 会直接报错或返回意外分组结果。
- 正确写法：两者必须字面一致，包括函数名、参数顺序、大小写（虽然不敏感，但建议统一）和空格（避免混淆）
- 如果字段是
datetimeoffset，DATETRUNC返回的仍是datetimeoffset类型，精度保留；若需按本地时间分组，得先用AT TIME ZONE转换，再截断，例如：DATETRUNC(month, order_time AT TIME ZONE 'China Standard Time') - 别在 GROUP BY 里嵌套其他函数包裹
DATETRUNC，比如CAST(DATETRUNC(day, d) AS DATE)—— 多余且易出错
WHERE 条件里别对字段套 DATETRUNC
比如写 WHERE DATETRUNC(day, order_date) = '2024-03-15'，SQL Server 无法使用 order_date 上的索引，全表扫描几乎不可避免。
- 应改写为范围查询：
WHERE order_date >= '2024-03-15' AND order_date - 如果要查整月，用：
WHERE order_date >= '2024-03-01' AND order_date ，比 <code>DATETRUNC(month, order_date) = '2024-03-01'安全得多 - 注意：日期字面量必须是
datetime2兼容格式（如'2024-03-01'），避免隐式转换引发时区或精度问题
DATETRUNC 和 DATE_BUCKET 别混用场景
DATETRUNC 是“对齐到自然周期起点”，比如 DATETRUNC(month, '2024-03-18') 总是返回 '2024-03-01'；而 DATE_BUCKET 是“按固定宽度切桶”，支持自定义起点，比如每 5 分钟一桶、从 '2024-01-01 00:02' 开始计数。
- 按日/月/年统计 → 用
DATETRUNC，语义清晰、兼容性好 - 按非标准周期聚合（如每15分钟、每2小时、跨天滑动窗口）→ 用
DATE_BUCKET，但注意它不向下兼容旧版本 - 二者返回值类型不同：
DATETRUNC返回原类型（datetime2还是datetime2），DATE_BUCKET也返回时间类型，但起始点由startdate决定，不是自然周期
性能与可读性的实际取舍点
用 DATETRUNC 写法更短、意图明确，但不代表它总比老方法快。尤其当字段没索引、或数据分布极不均匀时，执行计划可能并无改善。
- 如果已有
order_date索引，且查询条件本身已带高效范围过滤，DATETRUNC只用于 SELECT/GROUP BY，不影响走索引 - 但如果 GROUP BY 后还要接
HAVING COUNT(*) > 100，且数据倾斜严重，考虑是否该加覆盖索引（含DATETRUNC计算列） - 别为了用新函数强行改写简单逻辑——比如只按年统计，
YEAR(order_date)仍比DATETRUNC(year, order_date)少一次函数调用开销，差别小但真实存在
smalldatetime，结果秒数就归零；传入 datetime2(0)，毫秒部分就没了——这不是 bug，是设计，但如果你依赖毫秒级对齐做后续计算，得提前检查源字段精度。
