DATE_FORMAT在MySQL中用于时间分组易出错：周分组应优先用'%x-%v'处理跨年，月分组需注意字段类型和时区，GROUP BY时应避免函数导致索引失效，推荐生成列加索引或范围查询替代。
DATE_FORMAT 是 MySQL 里做时间分组最常用也最容易翻车的函数——它能按周、按月分组，但结果是否符合你的业务“周”或“月”，完全取决于你传的格式符和时区设置。
DATE_FORMAT 周分组：别默认用 %U 或 %u
MySQL 的 %U（周日为一周开始）和 %u（周一为一周开始）返回的是数字，但它们不考虑年份跨年问题。比如 2024-12-30 是周一，属于 2025 年第 1 周，但 DATE_FORMAT('2024-12-30', '%Y-%u') 会拼出 '2024-01'，错把 2025 年第 1 周算进 2024 年。
- 正确做法是用
%x-%v（ISO 周年 + ISO 周数），它自动处理跨年，DATE_FORMAT('2024-12-30', '%x-%v')返回'2025-01' - 如果业务强制要求“自然周”（比如每周一到周日），且不跨年对齐，才用
%Y-%u，但必须加WEEK(..., 1)确保模式一致 -
WEEK(date, mode)的mode值要和%u/%v匹配：mode=1 对应周一为起点、周数从 1 开始
DATE_FORMAT 月分组：别只写 %Y-%m
DATE_FORMAT(dt, '%Y-%m') 看似稳妥，但实际可能漏掉时区或字段类型带来的隐式转换问题。
- 如果
dt是DATETIME或TIMESTAMP，没问题；但如果是字符串（如'2024/03/15'），先得用STR_TO_DATE转成日期类型，否则DATE_FORMAT可能返回NULL - MySQL 8.0+ 支持
EXTRACT(YEAR_MONTH FROM dt)，返回整数（如 202403），比字符串更利于排序和索引下推，但注意它不补零，2024 年 3 月是20243，不是202403 - 想按“自然月”统计（如 3 月 1 日 00:00 到 3 月 31 日 23:59），直接用
DATE_FORMAT(dt, '%Y-%m')就够；但若需包含时区偏移（如 UTC 时间转东八区月统计），得先CONVERT_TZ(dt, '+00:00', '+08:00')再格式化
GROUP BY 时 DATE_FORMAT 的性能陷阱
在大表上直接 GROUP BY DATE_FORMAT(created_at, '%Y-%m')，几乎必然无法走 created_at 字段上的索引——因为函数包裹后，MySQL 无法做索引等值匹配。
- 替代方案：加一个生成列（Generated Column）并建索引，例如：
ALTER TABLE orders ADD COLUMN ym CHAR(7) GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m')) STORED;<br>CREATE INDEX idx_ym ON orders(ym);
- 或者改写查询，用范围条件代替函数分组：
WHERE created_at >= '2024-03-01' AND created_at ，再配合 <code>GROUP BY '2024-03' - 如果只是临时查，又不想改表结构，至少确保
created_at有索引，并用EXPLAIN看执行计划里type是否为range而不是ALL
真正难的不是写出 DATE_FORMAT，而是搞清你统计的“周”和“月”到底以什么为界、谁来定义起止、时区怎么对齐——这些一旦定错，数据就批量偏移，而且很难事后发现。
