MySQL中WEEK()默认按周日起点且第1周含1月1日，易致“第0周”或跨年错乱；须用WEEK(order_time, 1)按ISO标准（周一为始、含首个周四为第1周）实现自然周分组。

MySQL中用WEEK()函数按自然周分组的坑

直接用WEEK(order_time)分组，大概率会得到“第0周”或跨年错乱——因为WEEK()默认以周日为一周起点，且第1周定义为“包含1月1日的那一周”，和日常说的“周一到周日为一周”不一致。

要想真正按照自然周（周一至周日）进行分组，就必须明确指定模式参数：WEEK(order_time, 1)。这里的1代表着：周一作为每周的第一天，并且第1周是包含该年第一个周四的那一周（这可是ISO标准哦）。只有这样的组合，才能让2024-01-01（周一）落在2024年的第1周，而不是2024年的第53周。

常见错误写法：GROUP BY WEEK(order_time) → 没指定模式，结果依赖系统默认值，不可移植；WEEK(order_time, 0) → 周日为起点，和“自然周”认知冲突。

PostgreSQL里用EXTRACT(ISODOW)和date_trunc()对齐周一

PostgreSQL没有WEEK()函数，但date_trunc('week', order_time)默认截取到**周一00:00**，这恰好符合自然周起点。只要确认你的时区设置正确（如SET timezone = 'Asia/Shanghai';），它就是最简方案。

如果需要显示“2024-W01”这类格式，可以组合使用：TO_CHAR(order_time, 'IYYY-IW') —— IYYY是ISO年，IW是ISO周，二者严格对应自然周。

注意：EXTRACT(WEEK FROM order_time)在PostgreSQL里返回的是“年度第几周”，但它的起始日是周日，且第1周定义模糊，不能用于自然周统计。

SQL Server中DATEPART(week, ...)为什么总差一天

DATEPART(week, order_time)默认按周日为一周开始，且第1周从1月1日算起，和自然周完全错位。必须配合SET DATEFIRST 1（设周一为每周第一天），再用DATEPART(iso_week, order_time)获取ISO周数。

更为稳妥的方式是先将其归一化至周一，公式为：DATEADD(day, 2 - DATEPART(weekday, order_time), order_time)（假设DATEFIRST为7，也就是周日等于1）。之后，再使用CAST(... AS DATE)来截断时间部分，最后按照该日期进行分组。

关键点：iso_week参数只在SQL Server 2012+支持；低版本必须手动计算周一日期，否则周数永远偏移。

跨年边界问题：2024-12-31可能是2024年第1周

自然周的“年份”和日历年的“年份”不总一致。例如2024-12-31是周日，若2024-01-01是周一，则这一天属于2024年第1周。如果只用YEAR(order_time)拼接周数，会误标为“2024-W53”。

安全做法是统一用ISO年+ISO周：

• MySQL：YEARWEEK(order_time, 1)（返回202401这样的整数）
• PostgreSQL：TO_CHAR(order_time, 'IYYY-IW')
• SQL Server：FORMAT(order_time, 'yyyy-MM') + '-W' + RIGHT('0' + CAST(DATEPART(iso_week, order_time) AS VARCHAR(2)), 2)

《夸克》非常好用的免费AI浏览器

下载APP查看