如何在MySQL中按天、按周、按月统计数据_利用FROM_UNIXTIME与DATE_FORMAT

按天统计必须用 DATE(FROM_UNIXTIME())，别直接套 DATE_FORMAT()

很多朋友在MySQL里处理时间戳字段时，容易踩一个坑：直接用GROUP BY date_col来做日粒度聚合，结果发现行不通。为什么呢？因为时间戳通常是INT类型，存的是秒数，它本身不是日期类型。一个典型的错误写法是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年1月1日是周一，WEEK('2024-01-01', 0)返回1；而前一天的2023年12月31日是周日，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')这样的表达式建立函数索引，但它不支持对多个函数组合（如YEAR+MONTH）建立索引。

因此，更推荐的做法是统一使用字符串格式化：

• DATE_FORMAT(FROM_UNIXTIME(unix_time), '%Y-%m') —— 直接输出如'2024-03'的字符串。这样做的好处显而易见：结果天然有序、易于阅读，并且能够利用函数索引优化查询。
• 如果查询结果确实需要分别展示年份和月份两个独立的字段，可以在SELECT子句中使用YEAR(FROM_UNIXTIME(unix_time))和MONTH(FROM_UNIXTIME(unix_time))。但核心的分组操作（GROUP BY），仍然建议使用上面的DATE_FORMAT字符串。
• 尽量避免使用CONCAT(YEAR(...), '-', LPAD(MONTH(...),2,'0'))这种写法，它略显冗余，并且在性能上可能略逊一筹。

时区问题常被忽略：FROM_UNIXTIME() 默认用系统时区

这是数据统计中最隐蔽的“刺客”之一：时区不一致。你的MySQL服务器时区可能是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逻辑：或者，从一而终地使用UTC逻辑。即，所有FROM_UNIXTIME()的结果都视为UTC时间，后续的DATE_FORMAT(..., '%Y-%m-%d')也按UTC来解析。关键在于，整个数据链路必须保持一致。
• 在排查问题时，可以随时检查当前数据库会话的时区设置：SELECT @@time_zone。如果需要临时修改，可以使用SET time_zone = '+08:00'（注意，此设置仅对当前数据库连接有效）。

总而言之，时区问题不容小觑。没确认清楚时区就贸然跑统计，结果偏差最大可能达到24小时，而且这类问题排查起来往往非常棘手。