窗口函数本身不直接支持“自然周/月”分组，必须先用日期截断函数（如PostgreSQL的date_trunc、MySQL的DATE_SUB或DATE_FORMAT）将时间归一化为周一或每月1号起始的标量，再用于PARTITION BY或ORDER BY；滚动统计须配合ROWS或RANGE窗口帧，且需注意跨年边界、空周期处理及索引优化。
窗口函数本身不直接支持“自然周/月”分组，必须配合日期截断函数
SQL 窗口函数（如 sum() over()）的 PARTITION BY 和 ORDER BY 只能按字段或表达式分组/排序，不会自动识别“周一为一周开始”或“1号为一月开始”。所谓“自然周”指 ISO 周（YEAR-WEEK，周一为始，W01 是包含该年第一个周四的周），“自然月”指日历月（YEAR-MONTH，从每月 1 号 00:00 到下月 1 号前一秒）。必须先用日期函数把时间戳归到对应自然周期起点，再用于窗口划分。
常见错误是直接写 PARTITION BY EXTRACT(WEEK FROM order_time) —— 这只取数字周序（如 1–53），跨年时会把 2024-12-30（W53）和 2025-01-01（W01）强行分到不同组，但实际业务中这两日可能属于同一滚动周期；更糟的是没对齐周一/1号，导致窗口计算错位。
- PostgreSQL 推荐用
date_trunc('week', order_time)（自动对齐周一 00:00）或date_trunc('month', order_time) - MySQL 8.0+ 用
DATE_SUB(order_time, INTERVAL WEEKDAY(order_time) DAY)得周一，或DATE_FORMAT(order_time, '%Y-%m-01')得月初 - BigQuery 用
DATE_TRUNC(order_time, WEEK(MONDAY))或DATE_TRUNC(order_time, MONTH) - 注意：所有方案都要求原始时间字段是
TIMESTAMP或DATE类型，STRING必须先PARSE_TIMESTAMP或STR_TO_DATE
滚动统计必须用 RANGE 或 ROWS 指定物理偏移，不能只靠 PARTITION BY
“滚动”意味着每个结果行要聚合自身及之前 N 个自然周期的数据（例如“近3周累计销量”），这超出了 PARTITION BY 的静态分组能力，必须用窗口帧子句（ROWS BETWEEN ... AND CURRENT ROW 或 RANGE BETWEEN ... AND CURRENT ROW）。关键区别：
-
ROWS按行数偏移，安全但需确保每周期至少一行（否则跳过整个周期） -
RANGE按表达式值偏移（如RANGE BETWEEN INTERVAL '2 weeks' PRECEDING AND CURRENT ROW），语义更准，但仅部分数据库支持（PostgreSQL、BigQuery 支持，MySQL 不支持RANGE配合INTERVAL） - 若用
ROWS，必须先保证数据已按周期分组聚合（如每日一条），否则单日多订单会导致“一行=一天”，但滚动时会漏掉空周期
正确做法示例（PostgreSQL，近3周滚动）：
SELECT
date_trunc('week', order_time)::DATE AS week_start,
SUM(amount) AS weekly_amount,
SUM(SUM(amount)) OVER (
ORDER BY date_trunc('week', order_time)
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
) AS rolling_3w_amount
FROM orders
GROUP BY 1
ORDER BY 1;
跨年/跨月边界容易出错：ISO 周 vs 日历年周、月末最后一天处理
自然周最大陷阱是 ISO 周跨年问题：2024-12-30 属于 ISO 周 2025-W01（因2025-01-02是周四），但多数人直觉认为它属于“2024年第53周”。如果业务定义“自然周=ISO周”，就该用 TO_CHAR(ts, 'IYYY-IW')（PostgreSQL）或 FORMAT_DATE('%G-%V', ts)（BigQuery）；若按“日历年内的第几周”，则用 EXTRACT(YEAR FROM ts) + EXTRACT(WEEK FROM ts)，但必须手动处理 2024-12-30 这类日期被分到 2024-W53 还是 2025-W01。
- MySQL 的
WEEK()函数有 mode 参数：WEEK(dt, 1)表示周一为始、2024-12-30 返回 53，WEEK(dt, 3)才返回 1（ISO 模式） - 月末滚动时，
date_trunc('month', ...)在 2024-02-29 会得到 2024-02-01，没问题；但若用LAST_DAY()再加 1 天减 1 个月，易在闰年出错 - 所有数据库中，
ORDER BY的周期字段必须是确定性表达式（不能是CURRENT_DATE - INTERVAL '7 days'这种运行时变量），否则窗口排序失效
性能与索引：周期表达式必须可下推，避免全表计算
如果表有亿级订单，每次查询都算 date_trunc('week', order_time) 会拖慢速度。优化核心是让数据库能把周期计算下推到扫描层，甚至利用索引：
- 建生成列（Generated Column）并索引：PostgreSQL 中
ALTER TABLE orders ADD COLUMN week_start DATE GENERATED ALWAYS AS (date_trunc('week', order_time)::DATE) STORED，然后CREATE INDEX ON orders(week_start) - MySQL 5.7+ 支持函数索引：
CREATE INDEX idx_week ON orders ((DATE_SUB(order_time, INTERVAL WEEKDAY(order_time) DAY))) - BigQuery 不支持函数索引，但分区字段必须是原始时间字段（如
_PARTITIONTIME），周期计算只能放在 SELECT 中，此时应先用WHERE _PARTITIONTIME >= ...大幅剪枝 - 避免在
PARTITION BY中用多重嵌套函数（如EXTRACT(YEAR FROM ...) || '-' || LPAD(EXTRACT(MONTH FROM ...), 2, '0')），这会让优化器放弃使用索引
真正难的不是写出语法，而是确认业务说的“自然周”到底以什么为基准、是否接受 ISO 标准、空周期要不要补零——这些决定了你用 generate_series 做左连接，还是接受窗口结果里天然缺失的周期。
