需先将时间戳转为unix秒数，再除以300并floor取整，最后转回可读时间；各数据库函数名不同但逻辑一致，且group by与select中的表达式必须完全一致，同时注意时区和索引失效问题。
用 FLOOR 和时间单位换算实现 5 分钟分组
直接对 timestamp 字段做整除是行不通的，因为数据库不支持直接对时间类型做算术运算。必须先转成秒数（或分钟数），再用 FLOOR 截断到最近的 5 分钟起点。
核心思路：把时间戳转为 Unix 时间戳（秒数）→ 除以 300（5×60）→ FLOOR 取整 → 再转回时间。不同数据库函数名略有差异，但逻辑一致。
- PostgreSQL：
FLOOR(EXTRACT(EPOCH FROM ts) / 300)，再用TO_TIMESTAMP转回 - MySQL：
FLOOR(UNIX_TIMESTAMP(ts) / 300)，再用FROM_UNIXTIME - SQL Server：
DATEDIFF(second, '1970-01-01', ts) / 300，注意整除自动向下取整 - ClickHouse：
FLOOR(toUnixTimestamp(ts) / 300)，配合fromUnixTimestamp
避免 GROUP BY 中时间精度丢失
如果只用 FLOOR(...)/300 生成分组键，结果里显示的是数字（如 1712345678），没法直观读。得用对应函数还原成可读时间，且必须和分组表达式完全一致，否则会报错或分组错乱。
常见错误是分组用 FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300)*300)，但 SELECT 里写成了 DATE_FORMAT(...) 或漏了 *300，导致两者不等价。
- MySQL 正确写法：
GROUP BY FLOOR(UNIX_TIMESTAMP(ts)/300)，SELECT 里用FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(ts)/300) * 300) - PostgreSQL 必须保证
TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM ts)/300) * 300)和 GROUP BY 表达式一致 - 别用
DATE_TRUNC('minute', ts)直接截——它只能按整分钟截，不能按 5 分钟对齐
时区问题会让 5 分钟区间偏移
所有时间戳函数默认使用数据库所在时区（比如 UTC 或系统本地时区）。如果你的数据是北京时间（UTC+8），而数据库设的是 UTC，那算出来的 5 分钟边界就是 UTC 时间，和业务理解的“每小时 00/05/10… 分”不一致。
Prompt Log
下载
一款AI开发辅助工具，主要用于从 AI 编程会话日志（Clawdbot、Claude Code、Codex）中提取对话记录。该功能用于在用户要求导出提示词历史、会话日志或 `.jsonl` 格式的会话文件时使用，适合需要提升相关任务效率的用户。
- MySQL：确保
ts字段是TIMESTAMP类型（带时区转换），不是DATETIME - PostgreSQL：用
ts AT TIME ZONE 'Asia/Shanghai'先转时区，再提取 epoch - ClickHouse：
toTimeZone(ts, 'Asia/Shanghai')配合toUnixTimestamp - 测试方法：取一个已知时间点（如
'2024-04-05 10:07:22'），手动算它该归属哪个 5 分钟区间（应是10:05:00），再对比 SQL 输出
性能注意：别在 WHERE 条件里对字段做函数转换
如果写 WHERE FLOOR(UNIX_TIMESTAMP(ts)/300) = FLOOR(UNIX_TIMESTAMP('2024-04-05 10:05:00')/300)，会导致全表扫描——索引失效。
正确做法是把目标区间换算成时间范围：
WHERE ts >= '2024-04-05 10:05:00' AND ts <p>这样能走 <code>ts</code> 字段上的索引。如果查询频繁，建议额外建一个生成列（如 <code>ts_5min_bucket</code>）并索引它。</p><p>真正麻烦的不是怎么写，而是确认你的数据里有没有跨时区写入、有没有 <code>NULL</code> 或非法时间值——这些会在 <code>EXTRACT</code> 或 <code>UNIX_TIMESTAMP</code> 时静默失败或返回 0，悄悄污染分组结果。</p>
