MySQL 中基于 Unix 时间戳按未来日期分组求和的正确写法

本文详解如何在 MySQL 中对存储为 Unix 时间戳的日期字段，精准统计未来 1–7 天（仅按日期匹配，忽略时间）的记录数量，并修正因类型转换缺失导致的查询结果为 0 的常见错误。

本文详解如何在 MySQL 中对存储为 Unix 时间戳的日期字段，精准统计未来 1–7 天（仅按日期匹配，忽略时间）的记录数量，并修正因类型转换缺失导致的查询结果为 0 的常见错误。

在 MySQL 里，如果 mydate 这个字段存的是 Unix 时间戳（整型，单位为秒），那就不能直接拿 CURDATE() + INTERVAL N DAY 去比。道理很简单：前者本质上是整数，后者是日期类型，类型都不一致，自然没法直接判等。原查询里的 mydate = (CURDATE() + INTERVAL 1 DAY)，说白了就是在拿整数和日期硬做比较，这种写法注定匹配不上，所以结果才会一直是 0。

正确做法是：先将 Unix 时间戳转为日期类型，再剥离时间部分，最后与目标日期比对。核心函数组合为 DATE(FROM_UNIXTIME(mydate))，它将时间戳转为 YYYY-MM-DD 格式日期，确保与 CURDATE() 或其偏移量类型一致。

以下是优化后的完整 SQL 查询（支持未来 1 至 7 天逐日统计）：

SELECT 
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 1 DAY THEN 1 ELSE 0 END) AS p1,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 2 DAY THEN 1 ELSE 0 END) AS p2,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 3 DAY THEN 1 ELSE 0 END) AS p3,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 4 DAY THEN 1 ELSE 0 END) AS p4,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 5 DAY THEN 1 ELSE 0 END) AS p5,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 6 DAY THEN 1 ELSE 0 END) AS p6,
SUM(CASE WHEN DATE(FROM_UNIXTIME(mydate)) = CURDATE() + INTERVAL 7 DAY THEN 1 ELSE 0 END) AS p7
FROM mytable
WHERE DATE(FROM_UNIXTIME(mydate)) BETWEEN CURDATE() + INTERVAL 1 DAY AND CURDATE() + INTERVAL 7 DAY;

✅ 关键说明：

• FROM_UNIXTIME(mydate) 将 Unix 时间戳转为 DATETIME；
• DATE(...) 提取其日期部分（如 2024-06-15），彻底忽略时分秒；
• CURDATE() + INTERVAL N DAY 生成对应未来日期，类型为 DATE，可安全比对；
• WHERE 子句提前过滤范围，提升查询效率，避免全表扫描冗余计算。

⚠️ 注意事项：

• 若 mydate 为毫秒级时间戳（如 Ja vaScript 生成），需先除以 1000：DATE(FROM_UNIXTIME(mydate / 1000))；
• 确保 mydate 字段无 NULL 值，否则 FROM_UNIXTIME(NULL) 返回 NULL，影响 CASE 判断；
• 如需扩展至更多天数或动态生成列，建议在应用层拼接 SQL 或改用窗口函数+CTE（MySQL 8.0+）；
• 生产环境建议为 DATE(FROM_UNIXTIME(mydate)) 添加生成列并建索引，大幅提升大表性能。

该方案兼顾准确性、可读性与执行效率，是处理 Unix 时间戳日期聚合的推荐实践。