应使用 YEARWEEK(date, 1)，因其遵循 ISO 8601 标准，以周一为起点且第1周须含当年周四，确保跨年周归属准确（如 2024-12-30 正确归为 202453），避免 WEEK() 默认模式导致的跨年错位问题。
用 YEARWEEK() 还是 WEEK()？关键看是否要跨年对齐
MySQL 的 WEEK() 默认以周日为起点、且第1周是包含1月1日的那一周，这会导致 2024-12-30（周一）被算进 2025 年第1周——但业务上它属于 2024 年最后一周。真正靠谱的是 YEARWEEK(date, 1)：第二个参数 1 表示周一为每周起点，且按 ISO 8601 规则，第1周必须包含该年至少4天（即周四在当年内），这样 2024-12-30 就稳定落在 YEARWEEK('2024-12-30', 1) = 202453，不会跳到 2025。
常见错误是直接用 WEEK(order_time) 分组，结果 2024 年末和 2025 年初的订单混进同一组；或者用 YEAR(order_time) + WEEK(order_time) 拼字符串，但没指定 mode，导致跨年时 week 值错位。
-
YEARWEEK(date, 1)返回整数（如202453），可直接用于分组和排序，也方便前端解析 - 避免用
CONCAT(YEAR(date), '-', WEEK(date))，因为WEEK()默认 mode=0，和YEARWEEK(..., 1)不兼容 - 如果数据库是 PostgreSQL，对应函数是
EXTRACT(ISOYEAR FROM date)和EXTRACT(ISOWEEK FROM date)，需组合使用
按周统计销售额的最小可行 SQL
核心就是把日期转成周标识，再聚合。假设表叫 orders，金额字段是 amount，时间字段是 order_time：
SELECT YEARWEEK(order_time, 1) AS week_id, SUM(amount) AS total_sales FROM orders WHERE order_time >= '2024-01-01' GROUP BY week_id ORDER BY week_id;
注意：WHERE 条件里别用函数包裹 order_time（比如 YEARWEEK(order_time, 1) >= 202401），否则无法走索引。应尽量用范围条件提前过滤。
- 如果需要显示“2024-W53”这类格式，可用
CONCAT(YEAR(order_time), '-W', LPAD(WEEK(order_time, 1), 2, '0'))，但分组仍建议用YEARWEEK(..., 1)整数 - 空周（某周无销售）不会自动补零，需要 LEFT JOIN 生成的周序列，或由应用层处理
- 时区敏感：确保
order_time是 UTC 或统一时区存储，否则跨时区订单可能分到错误的周
跨年周的边界验证怎么做？
最直接的办法是查出每年12月25日到1月5日之间的记录，人工核对周归属：
SELECT order_time, YEARWEEK(order_time, 1) AS yw, WEEK(order_time, 1) AS w, YEAR(order_time) AS y FROM orders WHERE order_time BETWEEN '2024-12-25' AND '2025-01-05' ORDER BY order_time;
重点关注像 2024-12-30（周一）、2024-12-31（周二）、2025-01-01（周三）这种日期——它们都属于 ISO 第53周（202453），而 2025-01-06（周四）才进入 202501。如果发现 YW 值跳变异常，说明数据或函数参数有误。
- 别依赖日历 App 显示的“第几周”，不同系统默认规则不同；以
YEARWEEK(d, 1)输出为准 - 测试时务必覆盖闰年（如 2024）和非闰年（如 2025）的年末，因为 ISO 周数每年可能有 52 或 53 周
- 如果业务要求“自然周”（比如固定从周日到周六），那就得用
DATE_SUB(order_time, INTERVAL WEEKDAY(order_time) DAY)算周一，再分组，但此时跨年问题更隐蔽
BI 工具或应用层怎么接这个周维度？
返回的 week_id 是整数（如 202453），比字符串更易排序和计算同比。例如算“去年同期”销售额，只需：
SELECT
t1.week_id,
t1.total_sales,
t2.total_sales AS last_year_sales
FROM weekly_sales t1
LEFT JOIN weekly_sales t2
ON t2.week_id = t1.week_id - 100
AND t2.week_id DIV 100 = (t1.week_id DIV 100) - 1;这里 t1.week_id - 100 是粗略减一年，但要注意：202453 减 100 是 202353，而 2023 实际只有 52 周，所以严格做法是先拆解年份和周数，再用 YEARWEEK(DATE_SUB(...), 1) 反推日期。不过多数 BI 工具（如 Metabase、Superset）支持直接用 YEARWEEK 字段做相对时间过滤。
- 导出到 Excel 时，
202453会被当成数字自动去零，显示成 202453 —— 建议在 SELECT 中用LPAD(CAST(week_id AS CHAR), 6, '0')转成'202453'字符串 - 如果前端要做周选择器，别手写“2024-W01”到“2024-W53”，而是用
YEARWEEK(NOW(), 1)动态算当前周，再向前/向后推 - 真正麻烦的是财务关账：有些公司要求“2024财年最后一周”必须是某个固定日期范围，这时周统计只是辅助，最终还得按会计期间配置硬编码映射
