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周，而不是2023年第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+支持；低版本必须手动计算周一日期，否则周数永远偏移。
跨年边界问题：2023-12-31可能是2024年第1周
自然周的“年份”和日历年的“年份”不总一致。例如2023-12-31是周日，若2024-01-01是周一，则这一天属于2024年第1周。如果只用YEAR(order_time)拼接周数，会误标为“2023-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)
