SQL怎么判断某天是当年的第几周？三大数据库的“周数”陷阱与正确解法

先抛一个核心结论：在SQL里计算某一天是当年的第几周，这事儿听起来简单，做起来却是个不折不扣的“暗坑”集合地。不同数据库对“一周”的定义、起始日、甚至年份边界的处理都各有一套，稍不留神，跨年数据就可能出现令人费解的错误。下面，我们就来拆解MySQL、SQL Server和PostgreSQL这三大主流数据库的周数计算逻辑，看看如何避开陷阱，拿到符合ISO 8601标准的正确结果。

MySQL用WEEK()函数要注意模式（mode）参数

MySQL的WEEK()函数，如果你直接拿来就用，大概率会掉进坑里。它的默认行为是以周日作为一周的起点，并且将包含当年1月1日的那一周定义为第1周。这和大家通常理解的“ISO标准周”（周一为起点，且第一周必须包含至少4个周一）可不太一样。

举个例子就明白了：2024年1月1日是周一，WEEK('2024-01-01')会返回1；而2023年12月31日（周日）则返回52。表面看似乎合理，但问题往往藏在跨年边界。真正要获得符合ISO 8601标准的周数，必须显式指定mode参数：

SELECT WEEK('2024-01-01', 3); -- 返回1
SELECT WEEK('2023-12-31', 3); -- 返回52
SELECT WEEK('2024-12-30', 3); -- 返回53

这里的3是关键。它由两部分组成：1（表示周一为一周之始）加上2（表示第一周必须包含至少4个本周内的天数），合起来就是3。常用的mode值还有0（默认行为）和1（周一始，但第一周判定仍看1月1日）。记住，在MySQL里，不写mode参数，结果就不可控。

SQL Server用DATEPART(WEEK, ...)得配SET DATEFIRST

转到SQL Server，情况又变了。它的DATEPART(WEEK, ...)函数本身并不规定一周从哪天开始，这个决定权交给了会话级别的DATEFIRST设置。默认情况下，DATEFIRST是7（即周日）。这意味着，如果你的代码没有显式设置，一旦更换服务器或者连接池配置被重置，计算结果就可能突然“变脸”。

稳妥的做法是，在计算前显式控制一周的起始日：

SET DATEFIRST 1; -- 设置周一为每周第一天
SELECT DATEPART(WEEK, '2024-01-01'); -- 返回1
SELECT DATEPART(WEEK, '2023-12-31'); -- 返回52

当然，还有更省心的办法——直接使用DATEPART(isowk, ...)。这个选项直接遵循ISO周的逻辑，既不依赖DATEFIRST，也不受语言或区域设置的影响，可以说是首选方案：

SELECT DATEPART(isowk, '2024-01-01'); -- 返回1
SELECT DATEPART(isowk, '2024-12-30'); -- 返回53

PostgreSQL没有内置WEEK，得靠EXTRACT + timezone调整

PostgreSQL的处理方式更“现代”一些。它没有专门的WEEK()函数，而是通过EXTRACT(week FROM ...)来获取周数，并且它返回的就是ISO周数，相当于SQL Server的isowk，无需额外配置。但是，这里有一个极其容易忽略的细节：时区。

EXTRACT(week FROM ...)是严格按照UTC时间来计算的。如果你的时间字段是带时区的timestamptz

-- 错误：没考虑时区偏移
SELECT EXTRACT(week FROM '2024-01-01 00:00:00+08'::timestamptz);
-- 实际按2023-12-31 16:00:00 UTC计算，很可能返回52

-- 正确：先转换到本地时区再提取
SELECT EXTRACT(week FROM '2024-01-01 00:00:00+08'::timestamptz AT TIME ZONE 'Asia/Shanghai');