mysql时间间隔分组需用unix_timestamp与floor构造区间键，如每30分钟：from_unixtime(floor(unix_timestamp(created_at)/1800)*1800)；date_format适用于对齐自然周期（如每小时、每天），但不支持非对齐间隔；窗口函数无法替代group by实现分组聚合。
MySQL中用DATE_SUB和FLOOR实现时间间隔分组
直接用 GROUP BY 对原始时间字段分组无法满足“每5分钟”“每小时”这类动态间隔需求，必须把时间先映射成离散的区间标识。MySQL没有原生的time_bucket函数（8.0.28+才支持），得靠数学运算+日期函数构造分组键。
核心思路：把时间转为时间戳（秒数），除以间隔秒数取整，再乘回去得到该区间起始时间。例如每15分钟分组：FLOOR(UNIX_TIMESTAMP(dt) / 900) * 900，再用 FROM_UNIXTIME() 转回可读时间。
- 每30分钟分组：
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(created_at) / 1800) * 1800) - 每2小时分组：
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(created_at) / 7200) * 7200) - 注意时区：如果表中是
DATETIME且存的是本地时间，确保MySQL服务器时区与业务一致；若存UTC，查询时需用CONVERT_TZ调整
使用DATE_FORMAT做固定周期分组（适合日/月/年）
对“每小时”“每天”这种对齐自然周期的场景，DATE_FORMAT 更直观且无需计算时间戳。但它无法处理非对齐间隔（如“从13:17开始每10分钟”）。
- 按小时聚合：
DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00') - 按天聚合：
DATE_FORMAT(created_at, '%Y-%m-%d') - 按周聚合（周一为起点）：
DATE_SUB(created_at, INTERVAL WEEKDAY(created_at) DAY) - 陷阱：
DATE_FORMAT(NOW(), '%H')返回字符串，参与排序或计算时可能隐式转换失败，建议显式转成时间类型
窗口函数不适用，别被误导
有人尝试用 ROW_NUMBER() 或 LAG() 模拟分组，这是错误方向。窗口函数作用于已存在的行集合，不能改变行粒度；而时间分组本质是“把多行压缩成一行”，必须依赖 GROUP BY + 衍生分组键。
- 以下写法无效：
SELECT *, ROW_NUMBER() OVER (ORDER BY created_at) % 10 AS bucket FROM t—— 这只是编号，不是按时间间隔归并 - 聚合函数（如
COUNT(),AVG()）必须配合GROUP BY才有意义，单独用窗口函数无法替代 - 若需同时保留明细和分组统计，可用子查询或CTE先生成分组键，再JOIN回原表
性能和索引注意事项
基于函数的分组键无法直接走索引，WHERE created_at > '2024-01-01' 可以用索引加速过滤，但 GROUP BY FROM_UNIXTIME(FLOOR(...)) 阶段仍需全表扫描计算。
- 高频查询建议建生成列（MySQL 5.7+）：
ALTER TABLE t ADD COLUMN hour_bucket DATETIME GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')) STORED;，再对hour_bucket建索引 - 避免在大表上实时计算
UNIX_TIMESTAMP，尤其当间隔秒数是小质数（如7分钟=420秒）时，除法取整开销略高 - 测试时用
EXPLAIN FORMAT=TRADITIONAL确认是否用到索引，重点关注type是否为range或ref
实际应用中最容易忽略的是时区一致性——开发环境设的时区和生产库不一致，会导致分组结果偏移整点；还有就是误以为 DATE_ADD 能替代取整逻辑，其实它只做偏移，不解决分桶问题。
