BETWEEN不能用于GROUP BY分组，因其返回布尔值而非时间槽；正确做法是用DATE_FORMAT(login_time, '%Y-%m-%d %H:00:00')生成统一时间槽作为分组依据。
HOUR() 直接分组会导致跨天错乱，BETWEEN 用在 WHERE 里筛选可以，但绝不能用于 GROUP BY 时间槽
为什么不能用 BETWEEN 做分组依据
有人写 GROUP BY HOUR(login_time) BETWEEN 9 AND 17，这在 MySQL 中语法错误——BETWEEN 是布尔表达式，返回 TRUE/FALSE，无法作为分组键。更隐蔽的误用是：先用 BETWEEN 在 WHERE 里筛出某小时段，再对 HOUR() 分组，结果仍是单小时聚合，无法体现“各时间段”的连续性或滑动性。
-
BETWEEN只适合做行级过滤，不是时间切片工具 - 它不生成可分组的时间值，比如
HOUR(login_time) BETWEEN 9 AND 17不会产生 “09:00–10:00” 这样的槽位 - 若强行用
CASE WHEN HOUR(login_time) BETWEEN 9 AND 17 THEN 'day_shift' ELSE 'night_shift' END分组，会丢失小时粒度，无法统计每小时用户数
正确构造时间槽：用 DATE_FORMAT() 替代字符串拼接
要得到“2024-05-19 14:00:00”这种整点起始时间槽，必须用 DATE_FORMAT(login_time, '%Y-%m-%d %H:00:00')。这个值既是分组依据，也是展示字段，二者必须一致。
- 错误写法：
STR_TO_DATE(CONCAT(DATE(login_time), ' ', HOUR(login_time), ':00:00'), '%Y-%m-%d %H:%i:%s')—— 遇到NULL或非法时间直接报错 - 正确写法：
DATE_FORMAT(login_time, '%Y-%m-%d %H:00:00')—— 自动忽略NULL，时区安全，MySQL 8.0+ 支持索引下推 - 如果只要日期+小时（不要分钟秒），分组用
DATE_FORMAT(login_time, '%Y-%m-%d %H')，展示列用DATE_FORMAT(login_time, '%Y-%m-%d %H:00:00')，两者格式字符串必须完全相同
WHERE 中用 BETWEEN 筛选时的边界陷阱
想查“最近 24 小时内每小时活跃用户”，别写 WHERE login_time BETWEEN DATE_SUB(NOW(), INTERVAL 24 HOUR) AND NOW()。虽然语法合法，但 NOW() 在执行中可能漂移，且右边界包含秒级精度，容易漏掉最后一秒的记录。
- 推荐写法：
WHERE login_time >= DATE_SUB(NOW(), INTERVAL 24 HOUR) AND login_time -
BETWEEN a AND b等价于>= a AND ，而在高并发写入场景下可能让刚插入的记录被漏掉 - 如果业务要求严格按整点对齐（如每小时 00 分开始），应把范围起点向下取整：
DATE_SUB(DATE_FORMAT(NOW(), '%Y-%m-%d %H:00:00'), INTERVAL 24 HOUR)
去重逻辑必须和时间槽粒度对齐
同一个用户在 14:05 和 14:58 各登录一次，该算 1 人；但如果他在 14:59 和 15:01 登录，就该分别计入两个小时槽。这个行为由分组方式决定，不是 COUNT(DISTINCT) 能自动处理的。
- 错误假设：“加了
DISTINCT就不会重复”——其实重复与否取决于你分组的单位是否把两次登录划进同一组 - 若用
DATE_FORMAT(login_time, '%Y-%m-%d %H')分组，14:59 和 15:01 必然分属不同组，各自计 1 - 若误用
HOUR(login_time)分组，又没限定日期，那所有 14 点登录都压进一组，15 点的全进另一组，但跨天数据（如 23:59 和 00:01）就彻底错乱
真正难的不是写对函数，而是确认业务上“各时间段”指自然小时、滚动小时，还是运营自定义的班次区间；一旦粒度定义模糊，DATE_FORMAT() 再准也没用。
