date_format能按周/月分组，因其将日期转为统一字符串供group by归类；%u以周一为每周首日，%u以周日为首日；按月须用'%y-%m'避免'2024-5'等非标格式；字符串日期需先str_to_date转换；where中直接使用date_format会导致索引失效。
DATE_FORMAT 为什么能按周/月分组？
因为 DATE_FORMAT 不是“显示格式化”，而是“逻辑归类工具”——它把日期转成统一字符串，让 GROUP BY 能识别相同周期。比如所有 2024-03-01 到 2024-03-07 的日期，用 DATE_FORMAT(dt, '%Y-%u') 都变成 '2024-09'（第 9 周），自然就归到一组。
注意：%u 和 %U 行为不同：%u 把周一作为每周第一天，%U 把周日作为第一天；跨年周（如 2023-12-31）可能被算进下一年的第 1 周，得看业务是否接受。
按月汇总：最常用也最容易错的写法
正确写法是 DATE_FORMAT(dt, '%Y-%m')，不是 YEAR(dt) + MONTH(dt) 或 CONCAT(YEAR(dt), '-', MONTH(dt)) —— 后者在 MONTH(dt)=5 时会拼出 '2024-5'，而 '2024-05' 才是标准排序和比较的格式。
SELECT DATE_FORMAT(create_time, '%Y-%m') AS ym, COUNT(*) FROM orders GROUP BY ym;- 如果字段是字符串类型（如
VARCHAR存 '20240301'），必须先用STR_TO_DATE(create_time, '%Y%m%d')转成日期再格式化，否则DATE_FORMAT返回NULL - 索引失效风险：直接在
WHERE里对列用DATE_FORMAT（如WHERE DATE_FORMAT(create_time, '%Y-%m') = '2024-03'）会导致全表扫描；应改用范围查询：WHERE create_time >= '2024-03-01' AND create_time
按周汇总：要注意 ISO 周 vs 自定义周
MySQL 默认不严格遵循 ISO 8601，%x-%v（ISO 年+ISO 周）才可靠。例如 2024-01-01 是周一，DATE_FORMAT('2024-01-01', '%Y-%u') 返回 '2024-01'，但 2023-12-31（周日）也会返回 '2024-01'，实际属于 2023 年最后一周。
- 要严格按 ISO 周（周一为始，且全年至少 4 天在该年才算第 1 周）：用
DATE_FORMAT(dt, '%x-%v')，例如'2023-52'或'2024-01' - 想按“自然周”（比如固定从周日或周一算起，不管跨年）：用
WEEK(dt, 1)配合YEARWEEK(dt, 1)，其中第二个参数 1 表示周一为一周开始，0 表示周日 - 别用
WEEKOFYEAR()：它等价于WEEK(dt, 0)，以周日为起点，且不带年份，2023-12-31 和 2024-01-01 可能同属第 1 周，但年份混淆
性能和可读性兼顾的小技巧
直接在 SELECT 和 GROUP BY 里重复写 DATE_FORMAT(...) 不仅啰嗦，还容易写错。可以用子查询或派生表，但更推荐用 AS 别名后在 GROUP BY 引用（MySQL 5.7+ 支持）：
SELECT DATE_FORMAT(create_time, '%Y-%m') AS ym, COUNT(*) AS cnt FROM orders GROUP BY ym;
但如果需要在 HAVING 或 ORDER BY 中复用，仍建议显式写出表达式，避免某些旧版本 MySQL 解析异常。另外，DATE_FORMAT 返回的是字符串，不能直接参与日期运算；真要算“上周”得用 DATE_SUB(CURDATE(), INTERVAL 1 WEEK) 这类函数，而不是对格式化结果做字符串操作。
