按5分钟分组需将时间戳转为Unix秒数，用FLOOR除以300取整后再转回时间；MySQL用FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300)*300)，注意时区对齐和索引优化。
用 DATE_TRUNC 或 FLOOR 处理时间戳实现固定间隔分组
PostgreSQL、BigQuery、Trino 等现代 SQL 引擎支持 DATE_TRUNC，但只对标准单位（如 'hour'、'minute'）有效，不支持直接写 '5 minutes'。想按 5 分钟分组，得先“归整”时间戳：把原始时间向下取整到最近的 5 分钟边界。
核心思路是：把时间转成 epoch 秒数 → 用 FLOOR 对 300（5×60）取整 → 再转回时间类型。不同数据库语法略有差异：
- PostgreSQL：
SELECT DATE_TRUNC('second', TIMESTAMP '2024-01-01 10:12:47') - INTERVAL '1 second' * (EXTRACT(EPOCH FROM TIMESTAMP '2024-01-01 10:12:47')::int % 300)更推荐用FLOOR+TO_TIMESTAMP组合 - MySQL：没有
DATE_TRUNC，需用FLOOR(UNIX_TIMESTAMP(ts) / 300) * 300再转回FROM_UNIXTIME - SQLite：用
strftime('%s', ts)转秒数，再同上处理
MySQL 中按 5 分钟分组的可靠写法
MySQL 8.0+ 不支持 DATE_TRUNC 的自定义间隔，硬要用 DATE_FORMAT 会出错——它只截断到分钟级，无法对齐 5 分钟边界（比如 10:12:47 会被格式化成 10:12，而非 10:10）。
正确做法是基于 Unix 时间戳做数学归整：
SELECT FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(event_time) / 300) * 300) AS time_5min, COUNT(*) FROM logs GROUP BY time_5min;
注意：event_time 必须是 DATETIME 或 TIMESTAMP 类型；如果字段含毫秒（如 2024-01-01 10:12:47.123），UNIX_TIMESTAMP 会自动截断，不影响归整逻辑。
避免时区导致的分组偏移
时间分组结果是否“对齐本地业务时段”，取决于你用的是 UTC 还是业务时区的时间值。例如，你的日志存的是 UTC 时间，但运营看的是北京时间（UTC+8），直接按 UTC 归整会导致 5 分钟桶从 00:00:00 开始，而实际业务希望从 08:00:00 开始。
解决方法不是改服务器时区，而是显式转换：
- PostgreSQL：
DATE_TRUNC('minute', (event_time AT TIME ZONE 'Asia/Shanghai') - INTERVAL '2 minutes') + INTERVAL '2 minutes'—— 先转时区，再偏移对齐 - MySQL：用
CONVERT_TZ(event_time, '+00:00', '+08:00')替换原字段，再套入 Unix 时间戳归整逻辑 - 关键点：所有时间运算必须在统一时区下进行，否则
FLOOR归整出来的边界可能跨天或错位
性能与索引注意事项
对时间字段做函数运算（如 FLOOR(UNIX_TIMESTAMP(event_time))）会让 MySQL 无法使用 event_time 上的普通 B-tree 索引，导致全表扫描。
若查询频繁且数据量大，建议：
- 添加生成列（MySQL 5.7+）：
ALTER TABLE logs ADD COLUMN time_5min INT UNSIGNED AS (FLOOR(UNIX_TIMESTAMP(event_time) / 300)) STORED;
然后给该列建索引 - PostgreSQL 可建函数索引：
CREATE INDEX idx_logs_time_5min ON logs (FLOOR(EXTRACT(EPOCH FROM event_time) / 300));
- 避免在
WHERE条件里对时间字段用函数，例如WHERE FLOOR(...) = 12345仍走不了索引；应改写为范围查询：WHERE event_time >= '2024-01-01 10:10:00' AND event_time
归整逻辑本身很简单，但时区、索引、字段精度这三处最容易漏掉，一漏就查得慢或结果不对。
