用 HOUR() 提取小时并 GROUP BY 统计最直观高效，返回 0–23 整数，需确保时间字段为 DATETIME/TIMESTAMP，跨天需结合 DATE()，活跃用户须 COUNT(DISTINCT user_id)，注意过滤非法时间并添加日期范围条件提升性能。
用 HOUR() 提取小时并配合 GROUP BY 统计
直接对登录时间或行为时间字段用 HOUR() 函数截取小时部分，再按该值分组计数，是最常用也最直观的方式。注意它返回的是 0–23 的整数，不带日期信息，所以天然适合“每小时”维度的聚合。
常见错误是误用 DATE_FORMAT(time_col, '%H') —— 虽然结果一样，但 HOUR() 更轻量、无字符串转换开销，且在有索引的情况下更可能走函数索引（MySQL 8.0+ 支持函数索引时）。
- 确保时间字段类型是
DATETIME或TIMESTAMP，CHAR/VARCHAR类型需先用STR_TO_DATE()转换，否则HOUR()返回NULL - 如果业务跨多天，且需要区分“第几天的几点”，就不能只靠
HOUR()，得组合DATE()或DATE_SUB()做归一化 - 统计活跃用户通常要去重，务必用
COUNT(DISTINCT user_id)，而不是COUNT(*)
处理跨零点或非整点行为带来的偏差
“每小时活跃用户数”实际依赖你如何定义“活跃”。如果只看行为发生时刻的小时，会漏掉那些在 23:59 登录、持续活跃到次日 00:15 的用户；但如果按会话窗口（如 60 分钟滑动）统计，SQL 就没法单靠 GROUP BY 解决。
绝大多数场景下，采用“行为发生所在自然小时”已足够，但要注意：若原始数据里存在大量未来时间、0000-00-00 或非法时间，HOUR() 会返回 NULL，导致这部分记录被丢弃——建议加 WHERE time_col IS NOT NULL AND time_col != '0000-00-00 00:00:00' 过滤。
- 避免用
BETWEEN '2024-01-01 00:00:00' AND '2024-01-01 00:59:59'这类写法枚举每个小时：效率低、不可扩展、易出边界错误 - 若需补全缺失小时（比如某小时没数据就不显示），得用数字辅助表或
UNION ALL拼 0–23，不能依赖主表GROUP BY自动产出全部小时
性能关键：给时间字段建合适索引
HOUR(created_at) 本身无法直接使用普通 B+Tree 索引，因为函数改变了列值。MySQL 5.7 不支持函数索引，此时只能靠覆盖索引 + 全表扫描；MySQL 8.0+ 可显式创建函数索引：CREATE INDEX idx_hour ON events (HOUR(created_at))，但意义有限——因为 HOUR() 值分布极不均匀（24 个值），选择性太差。
真正有效的做法是：确保查询带日期范围条件，例如 WHERE created_at >= '2024-01-01' AND created_at ，然后在 <code>created_at 上建普通联合索引（如 (created_at, user_id)），让 MySQL 快速定位时间区间内数据，再做内存中 HOUR() 计算和分组。
- 不要单独为
HOUR()结果建索引，收益远低于维护成本 - 如果查询总带固定日期前缀（如每天跑一次昨日数据），可考虑按天分区，进一步减少扫描量
-
user_id字段若有空值，COUNT(DISTINCT user_id)会自动忽略，无需额外WHERE user_id IS NOT NULL，但明确写出更稳妥
一个能直接跑的示例语句
假设表叫 user_actions，行为时间存于 action_time，用户 ID 存于 user_id：
SELECT HOUR(action_time) AS hour_of_day, COUNT(DISTINCT user_id) AS active_users FROM user_actions WHERE action_time >= '2024-04-01 00:00:00' AND action_time < '2024-04-02 00:00:00' AND action_time IS NOT NULL GROUP BY HOUR(action_time) ORDER BY hour_of_day;
这条语句输出 0–23 行（只要对应小时有数据），每行是该自然小时内的去重用户数。如果某小时无数据，就不会出现——这点常被忽略，但恰恰是业务侧最容易质疑“为什么缺了 15 点的数据”的地方。
