优先使用 date_trunc('hour', event_time) 按小时聚合，postgresql/bigquery/trino 原生支持，语义清晰且时区可靠；mysql/sql server 不支持，需改用 date_format 或 from_unixtime+unix_timestamp 方案。
用 DATE_TRUNC 按小时聚合最稳妥，但得看数据库是否支持
PostgreSQL、BigQuery、Trino 等现代引擎原生支持 DATE_TRUNC('hour', event_time)，直接截断到小时精度，生成形如 '2024-06-15 14:00:00' 的时间点，适合做 GROUP BY。MySQL 和 SQL Server 不支持该函数，硬写会报错 function DATE_TRUNC does not exist。
实操建议：
- 先查文档确认当前数据库是否支持
DATE_TRUNC；不确定时可执行SELECT DATE_TRUNC('hour', NOW())测试 - 若支持，优先用它——语义清晰、时区处理可靠（如
DATE_TRUNC('hour', event_time AT TIME ZONE 'Asia/Shanghai')） - 注意字段类型：输入必须是
TIMESTAMP或TIMESTAMPTZ，STRING类型需先用TO_TIMESTAMP或类似函数转换
MySQL 用户别碰 MID，改用 DATE_FORMAT 或 FROM_UNIXTIME + UNIX_TIMESTAMP
MID(event_time, 1, 13) 看似能截出 '2024-06-15 14'，但这是字符串操作，无法正确处理跨天、夏令时或时区偏移，且一旦 event_time 格式稍有变化（比如带毫秒或不同分隔符），结果直接错乱。
正确做法：
- 用
DATE_FORMAT(event_time, '%Y-%m-%d %H:00:00')—— 简洁、可读、支持索引下推（如果字段上有函数索引） - 或更底层的
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(event_time) / 3600) * 3600)，适用于需要严格按 UTC 小时对齐的场景 - 避免在
WHERE条件里对event_time做函数运算，否则无法走索引；应把范围条件写成event_time >= '2024-06-15 14:00:00' AND event_time
SQL Server 要用 DATEADD + DATEDIFF 组合模拟小时截断
SQL Server 没有 DATE_TRUNC，也不能靠字符串截取靠谱处理时区。常见错误是写成 CONVERT(VARCHAR(13), event_time, 120)，这又回到字符串陷阱。
推荐写法：
-
DATEADD(HOUR, DATEDIFF(HOUR, 0, event_time), 0)—— 把event_time向前对齐到最近整点（UTC 时间逻辑） - 若字段含时区信息（如
DATETIMEOFFSET），先用SWITCHOFFSET(event_time, '+08:00')转目标时区，再套用上面公式 - 注意
DATEDIFF(HOUR, 0, ...)中的0是 SQL Server 的基准日期（1900-01-01），不是 Unix 时间戳，别和UNIX_TIMESTAMP混用
聚合结果里小时字段显示不整齐？检查时区和格式化逻辑
即使分组正确，最终 SELECT 出来的小时列可能显示为 2024-06-15 14:00:00.0 或带毫秒/微秒，看着像没截干净。这不是聚合问题，而是显示层或客户端默认行为。
解决方法：
- 显式格式化输出：PostgreSQL 用
TO_CHAR(truncated_hour, 'YYYY-MM-DD HH24:00')；MySQL 用DATE_FORMAT(truncated_hour, '%Y-%m-%d %H:00') - 避免在应用层再做字符串拼接——比如把
YEAR()、HOUR()单独取出来拼，既慢又易出错 - 如果下游是 Grafana 或 Superset，注意其时间字段解析依赖数据库返回的类型，尽量返回
TIMESTAMP而非字符串
真正容易被忽略的是时区一致性：日志写入时区、数据库服务器时区、查询会话时区、前端展示时区，四者只要有一个没对齐，小时分组就会偏移一两个小时，而且很难复现。上线前务必用带明确时区标识的日志样本验证一次全链路。
