应先截断datetime到小时粒度再分组，而非直接提取小时；sql server用dateadd(hour,datediff(hour,0,col),0)，postgresql用date_trunc('hour',col)，mysql用date_format(col,'%y-%m-%d %h:00:00')，sqlite用strftime('%y-%m-%d %h:00:00',col)；且where必须前置过滤时间范围。
SQL中用DATEPART或EXTRACT提取小时需要先对齐日期基准
直接对 datetime 字段用 DATEPART(HOUR, col)（SQL Server）或 EXTRACT(HOUR FROM col)（PostgreSQL）只能拿到「当天的小时数」，无法区分不同天的同一小时。比如 2024-01-01 14:00 和 2024-01-02 14:00 都会归到 HOUR=14，导致跨天数据被错误合并。
正确做法是先截断到小时粒度（即把分钟、秒清零），再按该截断后的时间分组。不同数据库的截断方式不同：
- SQL Server：
DATEADD(HOUR, DATEDIFF(HOUR, 0, col), 0) - PostgreSQL：
col::DATE + (EXTRACT(HOUR FROM col)::INT || ':00')::TIME或更简洁的DATE_TRUNC('hour', col) - MySQL：
DATE_FORMAT(col, '%Y-%m-%d %H:00:00')或FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(col) / 3600) * 3600) - SQLite：
strftime('%Y-%m-%d %H:00:00', col)
WHERE条件必须在GROUP BY之前过滤时间范围，否则性能极差
如果表有千万级记录，但只查最近7天的小时聚合，却在 HAVING 或聚合后过滤，数据库大概率会全表扫描再丢弃99%的数据。务必把时间范围判断写进 WHERE。
示例（SQL Server）：
SELECT
DATEADD(HOUR, DATEDIFF(HOUR, 0, created_at), 0) AS hour_start,
COUNT(*) AS cnt
FROM logs
WHERE created_at >= '2024-04-01' AND created_at <p>注意：用 <code> 而不是 <code>，避免因毫秒/时区导致边界遗漏。</code></code></p><h3>跨日区间聚合时，GROUP BY字段必须包含完整时间戳，不能只用HOUR()</h3><p>有人尝试这样写：<code>GROUP BY DATEPART(YEAR, t), DATEPART(MONTH, t), DATEPART(DAY, t), DATEPART(HOUR, t)</code>——语法可行，但可读性差、易出错，且无法利用时间字段上的索引（多数引擎不支持多列函数索引）。更糟的是，它把逻辑耦合进SQL，一旦要改成30分钟粒度就得重写全部。</p><p>推荐统一用「截断到小时」的表达式作为分组键，既语义清晰，也方便后续扩展（比如换成 <code>DATE_TRUNC('30 minutes', col)</code>）。</p>
- 别用
HOUR(created_at)单独分组 → 丢失日期信息 - 别用多个
DATEPART拼接字符串 → 类型不稳定，排序可能错乱 - 索引建议：在
created_at上建普通B-tree索引即可，截断表达式本身通常无法直接受益于函数索引（除非显式创建，如 PostgreSQL 的CREATE INDEX ON t (DATE_TRUNC('hour', created_at))）
时区处理不当会导致凌晨数据“偏移”一小时
如果业务服务器在 UTC+8，但数据库存储的是 UTC 时间，而你直接对原始字段做小时截断，结果会比本地时间晚8小时。例如用户在北京时间 2024-04-01 00:30 的操作，在 UTC 是 2024-03-31 16:30，按 UTC 截断就归到前一日的 16:00 小时桶里。
解决方案取决于数据库能力：
- PostgreSQL：用
created_at AT TIME ZONE 'Asia/Shanghai'先转时区，再DATE_TRUNC - MySQL：确保连接层或字段使用
TIMESTAMP类型（自动转时区），或显式调用CONVERT_TZ(created_at, '+00:00', '+08:00') - SQL Server：用
AT TIME ZONE（2016+），如created_at AT TIME ZONE 'UTC' AT TIME ZONE 'China Standard Time'
最稳妥的做法是在应用写入时就存成本地时区的无时区时间（如 DATETIME），或统一用 UTC 存储并在查询时显式转换——混用两种方式是线上小时聚合对不上的常见原因。
