MySQL中WEEK()分组结果错误因默认模式以周日为起点且第1周含1月1日，导致2023-12-31被归入2024年第1周；应改用YEARWEEK(date_col, 3)或DATE_FORMAT(date_col, '%x%v')按ISO标准分组，并添加生成列索引提升性能。
MySQL里用WEEK()分组为什么结果不对
直接用WEEK(date_col)分组常导致跨年周错乱或周一/周日起始不一致。默认模式下WEEK()以周日为起点、且第1周定义为“含1月1日的那一周”，2024年1月1日是周一，但WEEK('2024-01-01')返回1，而WEEK('2023-12-31')返回53——这会让2023年最后一天被归入2024年第1周的分组里。
实操建议：
- 显式指定模式参数：用
WEEK(date_col, 1)（周一为起点，第1周为含4个以上周一的那周）或更稳妥的WEEK(date_col, 3)（周一为起点，第1周为含1月4日的那周） - 避免纯
WEEK()：它不带年份，2023年第52周和2024年第1周可能同值为1，必须拼上年份 - 组合
YEARWEEK(date_col, 3)更可靠——它返回类似202401的整数，天然带年份且按ISO标准对齐
用DATE_FORMAT()按ISO周统计的正确写法
DATE_FORMAT()的%x和%v对应ISO周：前者是4位年份（基于周所属的星期四），后者是两位周数（01–53）。这是最接近“自然周”的方案，尤其适合报表场景。
实操建议：
- 分组语句写成：
GROUP BY DATE_FORMAT(created_at, '%x%v')，结果如'202401'、'202402' - 若需显示周起止日期，可搭配
STR_TO_DATE(CONCAT(DATE_FORMAT(created_at, '%x%v'), ' Monday'), '%x%v %W')算周一，再加6天得周日 - 注意：
%x不是%Y——2023-12-31是2024年第1周，%x返回2024，%Y返回2023
PostgreSQL或SQL Server用户别硬套MySQL函数
MySQL的WEEK()和DATE_FORMAT()在其他数据库不存在。PostgreSQL要用EXTRACT(week FROM date_col)配合EXTRACT(year FROM date_col + '3 days'::interval)模拟ISO周；SQL Server得用DATEPART(isowk, date_col)和DATEPART(year, DATEADD(day, 3 - DATEPART(weekday, date_col), date_col))。
实操建议：
- 跨数据库项目优先用ISO标准函数（如PostgreSQL的
to_char(date_col, 'IYYYIW')），输出格式与MySQL的DATE_FORMAT(..., '%x%v')一致 - 不要依赖
WEEKDAY()或DAYOFWEEK()——它们返回值范围和起点（0=Sunday还是1=Monday）各库不同 - 测试边界日期：选2023-12-31、2024-01-01、2024-12-30这几个点验证周归属是否符合业务预期
性能问题：函数包裹字段导致索引失效
写GROUP BY WEEK(created_at)或GROUP BY DATE_FORMAT(created_at, '%x%v')时，MySQL无法使用created_at上的普通B-tree索引，全表扫描不可避免。
实操建议：
- 高频按周查询的表，增加生成列：
ALTER TABLE orders ADD COLUMN week_key INT AS (YEARWEEK(created_at, 3)) STORED，再给week_key建索引 - 或者用分区表：按
YEARWEEK(created_at, 3)做RANGE分区，但需预估数据量，小表没必要 - 如果只是偶尔查，比加索引成本更低的方式是加覆盖索引：
INDEX(created_at, status, amount)（把SELECT字段也包进去）
ISO周的逻辑比表面复杂：它由星期四决定所属年份，不是简单看日期数字。哪怕只改一个参数，比如把WEEK(date, 1)换成WEEK(date, 3)，跨年那几周的归属就可能翻盘。上线前一定拿真实业务日期跑一遍，别信文档里的“标准”二字。
