DATE_TRUNC仅PostgreSQL等少数引擎支持且行为不一；按周需手动归一化（如MySQL用YEARWEEK、BigQuery用DATE_SUB+EXTRACT）；按月推荐DATE_TRUNC('month',date)但须注意时区；通用替代方案是YEAR*100+MONTH或ISO周编号；性能上应建表达式索引或冗余日期字段。
DATE_TRUNC 不能直接按“周”截断（PostgreSQL 除外）
绝大多数 SQL 引擎（如 MySQL、SQL Server、BigQuery 标准 SQL）压根没有 DATE_TRUNC 函数；只有 PostgreSQL 和某些云数仓（如 Redshift、Trino）支持，且行为不一致。PostgreSQL 的 DATE_TRUNC('week', ...) 默认以周日为起点，而 BigQuery 要求用 EXTRACT + DATE_SUB 手动算周一。别一上来就写 DATE_TRUNC('week', order_date)——大概率报错或结果不对。
常见错误现象：ERROR: function date_trunc(unknown, timestamp without time zone) does not exist（PostgreSQL 以外环境），或返回的“周首日”是周日但业务要求周一为起点。
- MySQL：改用
STR_TO_DATE(YEARWEEK(date, 1), '%Y%u')（1表示周一为每周第一天） - BigQuery：必须组合
DATE_SUB(date, INTERVAL EXTRACT(DAYOFWEEK FROM date) - 2 DAY)（2= 周一） - PostgreSQL：可用
DATE_TRUNC('week', date)，但需确认datestyle设置；更稳妥用date - EXTRACT(dow FROM date)::int + 1强制周一
按月截断时，DATE_TRUNC('month', ...) 是最简方案（但注意时区）
只要引擎支持 DATE_TRUNC（PostgreSQL/Redshift/Trino），DATE_TRUNC('month', date) 就能返回当月第一天 00:00:00 时间戳，比手写 MAKE_DATE(YEAR(date), MONTH(date), 1) 或字符串拼接安全得多。
关键陷阱在时区：如果字段是 TIMESTAMP WITH TIME ZONE，DATE_TRUNC('month', date) 按会话时区截断。例如 UTC 时间 '2024-03-01 01:00:00+00' 在东八区会话中可能被截成 '2024-02-01'（因为本地时间还是 3 月 1 日凌晨 9 点？不，等等——实际是 3 月 1 日 09:00，所以仍是 3 月；但若原值是 '2024-03-01 00:30:00+00'，本地显示 3 月 1 日 08:30，没问题；真正翻车的是跨时区聚合场景）。
- 统一用 UTC 存储时间，并显式转时区再截断：
DATE_TRUNC('month', date AT TIME ZONE 'Asia/Shanghai') - Redshift 中
DATE_TRUNC('month', date)对TIMESTAMP类型安全，但对DATE类型会隐式转成当天 00:00:00 再截，结果一样 - 避免用字符串函数（如
CONCAT(YEAR(date), '-', LPAD(MONTH(date), 2, '0'), '-01')），它生成的是字符串，无法参与日期计算
替代方案：用 DATEPART / EXTRACT 提取年月做分组（兼容性最强）
当无法依赖 DATE_TRUNC 时，最通用的办法是提取年、月数值组合成代理键，比如 YEAR(date) * 100 + MONTH(date) 得到 202403，或拼成 CONCAT(YEAR(date), '-', LPAD(MONTH(date), 2, '0'))。虽不如真实日期类型灵活，但所有主流 SQL 引擎都支持 YEAR/MONTH/EXTRACT。
按周则必须先归一化到周一（或周日），再提取年+周序号。MySQL 用 YEARWEEK(date, 1)（返回 202409），PostgreSQL 用 EXTRACT(YEAR FROM date) * 100 + EXTRACT(WEEK FROM date)，但注意 Postgres 的 WEEK 是 ISO 周（周一为始，第 1 周含当年第一个周四），和 MySQL 默认不同。
- BigQuery 推荐用
FORMAT_DATE('%G-%V', date)（ISO 年+ISO 周），确保跨年周不混乱（如 2024-01-01 可能属于 2023 年第 52 周） - SQL Server 用
DATEPART(iso_week, date)配合YEAR，但要注意YEAR返回日历年，需用ISO_WEEK规则调整年份 - 永远别用
WEEK(date)（MySQL）或DATEPART(week, date)（SQL Server）单独分组——它们只返回 1–53，跨年时重复
性能提醒：DATE_TRUNC 结果不可索引，但可建表达式索引
WHERE DATE_TRUNC('month', created_at) = '2024-03-01' 这类条件无法走 created_at 字段的普通 B-tree 索引——优化器没法反推原始值范围。但 PostgreSQL/Redshift 支持表达式索引：CREATE INDEX idx_orders_month ON orders (DATE_TRUNC('month', created_at))，这样就能加速按月查询。
而基于 EXTRACT(YEAR FROM date) 或 YEAR(date) 的条件，多数引擎也无法利用索引，除非你额外存一个 year_month 字段并建索引。
- 高频按月过滤的表，建议冗余存储
order_month DATE字段（值为每月 1 日），并建索引 - 用
created_at >= '2024-03-01' AND created_at 替代 <code>DATE_TRUNC条件，能完美命中索引 - BigQuery 不支持表达式索引，但分区表（按
_PARTITIONTIME）天然适配按月场景，优先考虑分区而非截断
时区、引擎差异、索引友好性——这三个点漏掉任何一个，都可能让“简单截断”变成线上慢查或数据偏差的源头。
