应优先使用 EXTRACT 和 DATE_TRUNC 实现跨数据库兼容的日期聚合，避免硬写 YEARWEEK() 或手算起始日；周聚合需联合 YEAR 与 WEEK 并注意时区转换，财年季度通过时间偏移法统一处理。
用 EXTRACT 和 DATE_TRUNC 控制聚合粒度，别硬写日期计算
直接拼 YEARWEEK() 或手算周一/季度初会出兼容性问题——MySQL 的 YEARWEEK() 默认周日为起点，PostgreSQL 没这函数，而 EXTRACT 在各主流数据库里语义统一：EXTRACT(YEAR FROM d)、EXTRACT(WEEK FROM d)、EXTRACT(QUARTER FROM d) 都返回整数，且行为可预测。PostgreSQL 还支持 DATE_TRUNC('week', d) 直接截到周一零点，比拼字符串更可靠。
实操建议：
-
EXTRACT(WEEK FROM order_time)得到 1–53 的周序号，但必须和EXTRACT(YEAR FROM order_time)联合使用，否则跨年周（如 2024-12-30 是 2025 年第 1 周）会被分错 - 想按“自然周”（周一至周日）聚合，PostgreSQL / ClickHouse 优先用
DATE_TRUNC('week', order_time)；MySQL 8.0+ 可用DATE_SUB(order_time, INTERVAL WEEKDAY(order_time) DAY) - 季度聚合统一用
EXTRACT(QUARTER FROM order_time)+EXTRACT(YEAR FROM order_time)，避免用QUARTER()（MySQL 特有，且不带年份上下文）
动态切换维度时，GROUP BY 和 SELECT 必须严格对齐
常见错误是只改 SELECT 中的日期表达式，忘了同步调整 GROUP BY，导致报错或逻辑错乱。比如把 SELECT EXTRACT(MONTH FROM ts) 改成 EXTRACT(WEEK FROM ts)，但 GROUP BY 还留着 EXTRACT(MONTH FROM ts)，结果每行都变成独立分组。
实操建议：
- 把维度表达式抽成 CTE 或子查询，让
SELECT和GROUP BY引用同一别名，例如：WITH t AS (SELECT *, EXTRACT(WEEK FROM order_time) AS week_id, EXTRACT(YEAR FROM order_time) AS year_id FROM sales) SELECT year_id, week_id, SUM(amount) FROM t GROUP BY year_id, week_id
- 如果用参数控制维度（如前端传
granularity = 'week'），SQL 层不建议用 CASE 动态生成GROUP BY—— 大部分数据库不支持在GROUP BY里用条件表达式做列切换，容易报语法错 - 真要动态，用应用层拼 SQL：根据参数决定插入哪组
EXTRACT字段，并确保SELECT、GROUP BY、ORDER BY三处完全一致
按周聚合时，注意时区和数据写入时间偏差
报表看的是业务发生时间（如订单创建时间），但数据入库可能延迟几小时，甚至跨天。如果数据库服务器时区是 UTC，而业务在东八区，EXTRACT(WEEK FROM created_at) 算的是 UTC 时间的周，和用户理解的“中国周一”不一致。
实操建议：
- 所有时间字段先转为目标时区再提取，PostgreSQL 用
created_at AT TIME ZONE 'Asia/Shanghai'，MySQL 用CONVERT_TZ(created_at, '+00:00', '+08:00') - 别依赖数据库服务器本地时区（
@@time_zone），它可能被意外修改，也不一定和业务对齐 - 如果数据源本身已存为本地时间（如全部写入前已转成 '2024-06-10 14:22:00' 格式且无时区标识），则无需转换，但需在 ETL 文档里明确标注，否则后续排查极难
季度聚合遇上财年怎么办？别改 EXTRACT(QUARTER)，改时间偏移
很多公司财年从 4 月开始（4–6 月为 Q1），但 EXTRACT(QUARTER FROM d) 固定按 1–3、4–6 划分。硬套 CASE WHEN 映射季度编号，会让 SQL 冗长且难以复用。
实操建议：
- 用时间偏移法：把原始时间减去 3 个月，再取标准季度，例如财年 Q1 =
EXTRACT(QUARTER FROM order_time - INTERVAL '3 months')（PostgreSQL）或QUARTER(DATE_SUB(order_time, INTERVAL 3 MONTH))（MySQL） - 偏移后记得同步调整年份：财年 2025 年 Q1 实际对应自然年 2024 年 4 月–2025 年 3 月，所以财年年份应为
EXTRACT(YEAR FROM order_time - INTERVAL '3 months') + (CASE WHEN EXTRACT(MONTH FROM order_time) >= 4 THEN 0 ELSE 1 END) - 这种偏移方式能复用现有索引（如果表上有
order_time索引），而用CASE表达式包裹时间字段会失效
时区处理和财年起始偏移是真正容易漏掉的点，尤其当报表从周报扩到月报、季报时，表面只是换几个函数，背后时间语义已经悄悄变了。
