按天统计必须用 DATE(FROM_UNIXTIME())，因时间戳为INT类型，DATE_FORMAT()直接作用于数字会转成0并返回'1970-01-01'；正确方式是先转日期再截取，确保分组准确且支持函数索引。
按天统计必须用 DATE(FROM_UNIXTIME())，别直接套 DATE_FORMAT()
MySQL 中时间戳字段（INT 类型存秒级时间）不能直接用 GROUP BY date_col 做日粒度聚合——因为它是整数，不是日期类型。常见错误是写成 GROUP BY DATE_FORMAT(unix_time, '%Y-%m-%d')，结果为空或错乱：因为 DATE_FORMAT() 对纯数字不识别，会静默转成 0，再格式化成 '1970-01-01'。
正确做法是先转为日期类型，再截取日期部分：
-
DATE(FROM_UNIXTIME(unix_time))—— 最简洁可靠，返回DATE类型，可直接用于分组和索引（如果字段有函数索引） - 避免用
FROM_UNIXTIME(unix_time) + 0或CAST(unix_time AS DATETIME)，它们可能因时区或精度出问题 - 若需兼容 MySQL 5.6 以下版本（不支持函数索引），建议在应用层或通过生成列预计算
date_day字段
按周统计要注意 WEEK() 的模式和起始日
WEEK() 默认以周日为一周开始，且模式 0（WEEK(date, 0)）把 1 月 1 日所在周算作第 1 周，容易跨年错位。比如 2024-01-01 是周一，但 WEEK('2024-01-01', 0) 返回 1，而 WEEK('2023-12-31', 0) 返回 53 —— 同一自然周被拆到两个年份里。
更稳妥的方案是用 YEARWEEK() 并显式指定模式：
-
YEARWEEK(FROM_UNIXTIME(unix_time), 1)：模式 1 表示周一为每周起点，且第 1 周必须包含 4 个以上周一（ISO 8601 标准） - 结果是整数（如 202405），可用于分组；也可配合
STR_TO_DATE(CONCAT(YEARWEEK(...), ' Monday'), '%X%V %W')还原周一日期 - 注意：如果业务要求“自然周”（周日～周六），改用模式 0，但务必在 WHERE 中加年份过滤，防止跨年聚合污染
按月统计优先用 DATE_FORMAT(..., '%Y-%m')，而非 YEAR()+MONTH()
写 GROUP BY YEAR(FROM_UNIXTIME(t)), MONTH(FROM_UNIXTIME(t)) 看似合理，但会导致排序错乱：(2023,12) 和 (2024,1) 在字符串排序中相邻，数值排序却跳跃。更严重的是，它无法利用函数索引（MySQL 8.0+ 支持 DATE_FORMAT(col, '%Y-%m') 索引，但不支持多函数组合索引）。
推荐统一用字符串格式化：
-
DATE_FORMAT(FROM_UNIXTIME(unix_time), '%Y-%m')—— 输出如'2024-03'，天然有序、易读、可索引 - 若需返回年份和月份分开的字段，用
YEAR(FROM_UNIXTIME(unix_time))和MONTH(FROM_UNIXTIME(unix_time))作为 SELECT 列，但 GROUP BY 仍用DATE_FORMAT字符串 - 避免
CONCAT(YEAR(...), '-', LPAD(MONTH(...),2,'0'))，冗余且性能略差
时区问题常被忽略：FROM_UNIXTIME() 默认用系统时区
你的服务器时区是 CST（UTC+8），但应用写入的时间戳可能是 UTC，或者前端传的是本地时间。一旦时区不一致，FROM_UNIXTIME(1712000000) 可能解析成 '2024-04-01 08:00:00'（UTC）或 '2024-04-01 16:00:00'（CST），导致同一天的数据被分到两天。
解决方法只有两个：
- 统一存储为 UTC 时间戳，并在 SQL 中显式指定时区：
FROM_UNIXTIME(unix_time, '+00:00')，再用CONVERT_TZ(..., '+00:00', '+08:00')转本地（适合报表类查询） - 或全程用 UTC 逻辑：所有
FROM_UNIXTIME()结果视为 UTC，DATE_FORMAT(..., '%Y-%m-%d')也按 UTC 解析 —— 关键是前后一致 - 检查当前会话时区：
SELECT @@time_zone；临时修改：SET time_zone = '+08:00'（仅当前连接有效）
没确认时区就跑统计，结果偏差可能高达 24 小时，而且很难排查。
