最快的时间分组方式是用GROUP BY截断时间字段，但需解决对齐不准、跨天混入、索引失效问题；SQL Server用DATEADD(HOUR, DATEDIFF(HOUR, 0, login_time), 0)，MySQL用FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(login_time)/3600)*3600)，PostgreSQL用DATE_TRUNC('hour', login_time AT TIME ZONE 'Asia/Shanghai')，且WHERE条件须避免函数导致索引失效。
直接用 GROUP BY 对时间字段做截断分组，是最快也最常用的方式；但多数人卡在时间对齐不准、跨天混入、索引失效这三处。
怎么把时间字段对齐到整点/整日再分组？
直接 DATEPART(HOUR, login_time)（SQL Server）或 HOUR(login_time)（MySQL）会丢掉日期部分，导致 2026-07-20 23:00 和 2026-07-21 00:00 都算成“0点”，实际分属不同小时段。
- SQL Server 推荐用
DATEADD(HOUR, DATEDIFF(HOUR, 0, login_time), 0)，它把任意时间截断到最近的整点（向下取整） - MySQL 推荐用
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(login_time)/3600)*3600)，原理相同，避免DATE_FORMAT(login_time, '%Y-%m-%d %H:00:00')在时区切换时出错 - PostgreSQL 用
DATE_TRUNC('hour', login_time)最简洁，但注意默认按 UTC 截断，业务在东八区就得先AT TIME ZONE 'Asia/Shanghai'
为什么加了索引还是慢？
建了 login_time 索引，但查询里用了函数（比如 DATEPART(HOUR, login_time)），数据库就无法走索引，只能全表扫描。
- 必须让 WHERE 条件和 GROUP BY 表达式都基于原始字段——先用范围过滤再分组：
WHERE login_time >= @start_time AND login_time - 索引要覆盖查询字段，比如查
COUNT(DISTINCT user_id)，那就建复合索引：CREATE INDEX idx_login_time_uid ON log_table (login_time, user_id) - MySQL 8.0+ 可考虑函数索引：
CREATE INDEX idx_hour ON log_table ((DATE_ADD(login_time, INTERVAL -SECOND(login_time)-MINUTE(login_time)*60 SECOND)))，但维护成本高，一般不优先选
如何避免跨天数据被错误归并？
当统计“每小时活跃用户”时，如果只按 HOUR(login_time) 分组，23 点和次日 0 点会挤在同一组，结果虚高。
- 关键不是只看小时数，而是构造带日期的完整时间桶，例如 SQL Server 的
CONVERT(CHAR(13), login_time, 120)得到'2026-07-21 08'字符串，再GROUP BY - 更稳妥的是生成时间桶字段：
SELECT DATEADD(HOUR, DATEDIFF(HOUR, 0, login_time), 0) AS hour_bucket, COUNT(DISTINCT user_id) FROM log_table GROUP BY hour_bucket - 别漏掉过滤无效记录：排除
user_id IN ('system', 'probe')和 refresh_token 刷新行为，否则凌晨自动续期会刷高“活跃”数值
真正难的不是写对 GROUP BY，而是确认时间字段类型是否为 DATETIME 或 TIMESTAMP；如果是字符串，STR_TO_DATE() 或 CONVERT() 转换一步不能少，否则截断逻辑全失效。
