最简单可靠的按日分组方式是用DATE()提取日期后GROUP BY；直接GROUP BY datetime_column会因时分秒差异导致每行单独成组，无法实现按天统计。
直接用 DATE() 提取日期再 GROUP BY，是最简单可靠的按日分组方式；别在 GROUP BY 里套复杂表达式，容易触发 MySQL 5.7+ 的 sql_mode=only_full_group_by 报错。
为什么不能直接 GROUP BY datetime_column？
因为 datetime_column 含时分秒，哪怕两条记录是同一天，只要时间不同，MySQL 就视为不同分组。结果就是每行都单独成组，起不到“按天统计”的作用。
常见错误现象：SELECT datetime_column, COUNT(*) FROM logs GROUP BY datetime_column 返回几百上千行，但你只想要 30 行（对应 30 天）。
- 必须先剥离时间部分，只保留日期值
-
DATE(datetime_column)是最轻量、索引友好的方式（如果该列有前缀索引或函数索引支持） - 避免用
DATE_FORMAT(datetime_column, '%Y-%m-%d')—— 它返回字符串，无法利用日期索引，且在严格模式下可能被判定为非确定性表达式
DATE() 和 DATE_FORMAT() 在 GROUP BY 中的区别
DATE() 返回的是 DATE 类型值（如 2026-10-14），语义清晰、可比较、能走索引；DATE_FORMAT() 返回字符串，类型不一致，排序和分组效率低，还容易因区域设置导致意外行为。
实操建议：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 优先写
SELECT DATE(created_at) AS day, COUNT(*) FROM orders GROUP BY DATE(created_at) - 如果要复用别名，MySQL 允许
GROUP BY day，但注意：这是语法糖，底层仍会重复计算DATE(created_at)，性能无提升 - 想按周/月/年分组？用
YEARWEEK(created_at)、DATE_FORMAT(created_at, '%Y-%m')等，但要清楚它们返回的是整数或字符串，不是原生日期类型
WHERE 和 GROUP BY 的顺序影响结果准确性
过滤必须在分组前完成，否则统计口径会出错。比如查“近7天每天的订单数”，错误写法是先把全部数据 GROUP BY DATE(created_at)，再用 HAVING 筛日期——HAVING 是对分组后结果过滤，但分组时已包含历史数据，浪费资源且可能因索引失效变慢。
正确做法：
- 先用
WHERE created_at >= '2026-10-08'限定原始数据范围 - 再
GROUP BY DATE(created_at) - 这样 MySQL 能用上
created_at上的索引，大幅减少扫描行数
容易被忽略的 NULL 和时区问题
DATE(NULL) 返回 NULL，所有 created_at 为 NULL 的记录会被归到同一个分组里。如果你没意识到这点，看到 “NULL 日订单数 = 42” 就会误以为是某天的数据。
另外，DATE(created_at) 按服务器时区解析。如果应用写入的是 UTC 时间，而 MySQL server_time_zone 是 +08:00，那 2026-10-14 00:00:00 UTC 会被转成 2026-10-14 还是 2026-10-13？取决于你的配置。生产环境务必确认时区一致性，必要时显式转换：DATE(CONVERT_TZ(created_at, '+00:00', '+08:00'))。
