datepart 更适合报表统计，因其专用于将连续时间离散化为年/月/周/季度等整数维度以支持分组聚合；dateadd 则用于动态时间偏移计算，如“最近30天”筛选或同比对齐，不能替代 datepart 做维度提取。
DATEPART 本身不比 DATEADD “更适合”报表统计，它俩根本不是同一类操作——一个拆解时间，一个移动时间。用错函数会导致分组错乱、聚合失真，而不是性能差异。
DATEPART 的核心作用是分组与切片
报表统计最常做的动作是“按年/月/周/季度汇总”，这本质是把连续时间离散化为维度标签。DATEPART 正是干这个的：DATEPART(month, order_date) 返回整数 8，能直接用于 GROUP BY 或 CASE WHEN；而 DATEADD 返回的是另一个日期值（比如把 '2026-08-15' 变成 '2026-09-15'），无法天然构成统计维度。
- 错误写法：
GROUP BY DATEADD(month, 0, order_date)—— 这只是原样返回日期，没做任何归类，每个毫秒都可能产生新分组 - 正确写法：
GROUP BY DATEPART(year, order_date), DATEPART(month, order_date)—— 明确按年月整数切片 - 注意：不要混用缩写和全称，
DATEPART(yy, ...)和DATEPART(year, ...)行为一致，但可读性差，建议统一用全称
DATEADD 在报表里通常只用于动态时间窗口计算
DATEADD 的典型报表场景是“最近 N 天”“去年同期”这类带偏移的筛选逻辑，而非分组依据：
- 筛选条件：
WHERE order_date >= DATEADD(day, -30, GETDATE())—— 定义数据范围 - 同比计算：
DATEADD(year, -1, order_date)配合自连接或窗口函数对齐去年同日 - 但它不能替代 DATEPART 做维度提取：比如想看“每月销售额”，你不能
GROUP BY DATEADD(month, DATEDIFF(month, 0, order_date), 0)—— 这是绕远路且易出错的模拟，不如直接DATEPART
容易踩的坑：混淆 DATEPART 和 DATENAME，或忽略时区/边界
DATEPART 返回整数，DATENAME 返回字符串（如 DATENAME(weekday, '2026-08-27') 返回 'Thursday'）。在排序或数值计算中混用会导致隐式转换失败或顺序错乱。
- 按周统计时，
DATEPART(week, ...)的结果依赖于服务器DATEFIRST设置（默认周日为第 1 天），中国业务常用SET DATEFIRST 1让周一为每周起点 - 用
DATEPART(quarter, ...)分组没问题，但别用它算“本季度第一天”——那是DATEFROMPARTS+DATEADD的组合活 - 如果字段是
DATETIME2类型，DATEPART行为与DATETIME一致，无需额外适配
真正容易被忽略的是：DATEPART 对 NULL 输入直接返回 NULL，而报表中未处理的 NULL 分组常导致总数对不上。加一句 WHERE order_date IS NOT NULL 比后期排查数据缺口省力得多。
