应优先用yearweek(date_col, 1)按周一为始的自然周分组，返回202415类整数；月统计用date_format(date_col, '%y-%m')生成字符串，避免跨年错误与歧义，且where范围须与分组逻辑严格匹配。
用 YEARWEEK() 和 DATE_FORMAT() 分别处理周/月分组
MySQL 里没有直接的“按自然周”或“按业务月”聚合函数，得靠日期函数把时间字段规整成可分组的标量。核心是：周统计优先用 YEARWEEK(date_col)（默认周日为一周开始），它返回类似 202415 这样的整数，天然支持排序和差值计算；月统计用 DATE_FORMAT(date_col, '%Y-%m') 更稳妥，比 YEAR(date_col)*100 + MONTH(date_col) 可读性强，且避免跨年时的边界错误。
常见错误是混用 WEEK() 单独使用——它只返回 1–53，不带年份，2023 年第 1 周和 2024 年第 1 周会撞组；还有人用 MONTH() 直接分组，结果 1 月和 2024 年 1 月、2025 年 1 月全被归到同一组。
-
YEARWEEK()第二个参数可选1（周一为周始）或2（周日为周始），国内业务多数按周一算，建议显式写YEARWEEK(date_col, 1) - 如果数据含未来时间或 NULL，
YEARWEEK(NULL)返回NULL，会导致该行被 GROUP BY 排除，需提前用WHERE date_col IS NOT NULL过滤 -
DATE_FORMAT(date_col, '%Y-%m')输出字符串，排序时按字典序，但 '2024-01' PERIOD_DIFF(EXTRACT(YEAR_MONTH FROM NOW()), EXTRACT(YEAR_MONTH FROM date_col))
计算环比增长：用窗口函数 LAG() 拿上期值
增长统计不是简单求和，关键在“比上一期涨了多少”。MySQL 8.0+ 支持窗口函数，LAG() 是最直接的解法：按分组字段排序后，取前一行的聚合结果。比如周级订单量增长，先按 YEARWEEK(create_time, 1) 分组求和，再用 LAG(SUM(amount)) OVER (ORDER BY week_key) 拿上周值。
容易忽略的是排序字段必须和分组键严格一致，否则 LAG() 的“上一行”可能来自不同周。例如错误写法：ORDER BY create_time —— 同一周内多条记录时间不同，窗口顺序乱了，上周值就拿错了。
- 必须用分组后的聚合键排序，如
ORDER BY YEARWEEK(create_time, 1)或ORDER BY DATE_FORMAT(create_time, '%Y-%m') -
LAG()默认返回NULL当无上期数据，计算增长率时要加IFNULL(prev_value, 0)避免除零或 NULL 传播 - 如果数据库是 MySQL 5.7，没有窗口函数，只能用自连接或子查询模拟，性能差且易出错，建议升级或改用应用层计算
处理“自然周起止日”：用 STR_TO_DATE() 反推周一/周日
运营报表常要求显示“2024-04-01 至 2024-04-07”这样的区间标签，而 YEARWEEK() 只给数字。此时需反向构造日期：已知某天属于第几周，求该周周一或周日。MySQL 提供 STR_TO_DATE() 配合格式符实现。
典型错误是硬编码加减天数，比如 date_col - INTERVAL WEEKDAY(date_col) DAY 算周一——但 WEEKDAY() 周一返回 0，周日返回 6，若服务器 default_week_format 被改过，结果会偏移。
- 安全做法：用
STR_TO_DATE(CONCAT(yearweek_col, ' Monday'), '%X%V %W')，其中%X%V解析年份+ISO周，%W固定为 Monday 字符串 - 若用
YEARWEEK(date_col, 1)（周一为始），则STR_TO_DATE(CONCAT(YEARWEEK(date_col, 1), ' Monday'), '%x%v %W')可得当周周一 - 注意
%x%v和%X%V区分大小写：%x是 ISO 年（基于周四所在周），%X是对应 ISO 周的年份，通常用%x%v更准
避免跨月/跨周数据被重复或遗漏
业务数据的时间字段常是 datetime 类型，但统计口径可能是“创建时间所在周”或“支付时间所在月”。一旦字段选错，比如用下单时间分周、却用支付时间过滤条件，就会漏掉未支付的单子，导致周粒度数据失真。
另一个坑是 WHERE 条件写成 create_time >= '2024-01-01'，表面看是查全年，但如果 create_time 有秒级精度，而你想统计 2024 年第 1 周（1月1日是周一），实际应包含 2023-12-25 至 2024-01-01 的数据——这时 WHERE 条件必须覆盖完整周期，不能只卡年份。
- WHERE 中的时间范围要根据分组逻辑反推：若按
YEARWEEK(create_time, 1)统计，则 WHERE 应覆盖所有目标周的原始日期范围，而不是简单按年/月切 - 对多状态业务（如订单有创建、支付、完成），明确统计维度是哪个状态的时间点，避免混用
- 测试时用小范围数据手工验算：挑一个周，查出所有原始记录，手动按周一到周日分组加总，再和 SQL 结果比对
实际跑通的关键在于：分组函数、窗口排序字段、WHERE 时间范围三者必须基于同一套时间语义。哪怕函数写对了，只要 WHERE 漏了一天，或者窗口 ORDER BY 用了原始时间而非分组键，增长曲线就会跳变。
