最直接的方式是用 TIMESTAMPDIFF 函数计算时间差后分组，它返回整数、天然适合分组且不依赖时区；需避免误用 DATEDIFF 或直接相减，并提前处理 NULL 值。
用 TIMESTAMPDIFF 计算时间差再分组
MySQL 中最直接的方式是用 TIMESTAMPDIFF 函数算出两个时间字段的差值（单位可选秒/分/小时/天），再对结果做 GROUP BY。注意它返回的是整数，天然适合分组，且不依赖时区转换逻辑。
常见错误是误用 DATEDIFF——它只取日期部分，忽略时分秒，导致跨天但不足24小时的记录被归为0天；或者直接相减（如 end_time - start_time），在 MySQL 中会得到格式混乱的伪数值，无法可靠分组。
-
TIMESTAMPDIFF(HOUR, start_time, end_time)得到小时级差值，适合按“每6小时”“每12小时”分组 - 若需自定义区间（如每30分钟一组），先算出分钟差：
TIMESTAMPDIFF(MINUTE, start_time, end_time)，再用FLOOR(minutes / 30)归桶 - NULL 值必须提前处理，否则整组会被过滤掉：
WHERE start_time IS NOT NULL AND end_time IS NOT NULL
PostgreSQL 用 EXTRACT + INTERVAL 运算
PostgreSQL 没有 TIMESTAMPDIFF，得靠 EXTRACT 提取时间单位，或直接用区间运算。关键点在于：两个 TIMESTAMP 相减得到的是 INTERVAL 类型，不能直接 GROUP BY，必须转成数值。
推荐写法是先相减得 INTERVAL，再用 EXTRACT(EPOCH FROM ...) 转成秒数，最后按需缩放。例如：
SELECT FLOOR(EXTRACT(EPOCH FROM (end_time - start_time)) / 3600) AS hours_bucket, COUNT(*) FROM events GROUP BY hours_bucket;
- 避免用
EXTRACT(HOUR FROM (end_time - start_time))——它只取区间中的“小时”字段，丢弃了分钟和秒，3.9 小时和 3.1 小时都会变成 3 - 如果字段是
TIMESTAMPTZ，相减结果自动按 UTC 对齐，无需额外AT TIME ZONE，除非你明确要本地时区逻辑 - 负值（end_time HAVING hours_bucket >= 0 或前置校验
动态区间分组必须绕开的坑
所谓“动态”，常指按业务规则生成非固定宽度的桶（比如“0–5分钟、5–15分钟、15–60分钟、>60分钟”）。这时候不能只靠 FLOOR 或 CASE WHEN 写死，容易漏覆盖或边界重叠。
- 用
CASE WHEN时，务必检查边界是否闭合：写成WHEN diff_sec ，而不是 <code>BETWEEN 0 AND 300（后者包含 300 秒，而下一个条件又可能从 300 开始，造成重复） - 别在
GROUP BY里重复写长表达式，MySQL 8.0+ 和 PostgreSQL 支持列别名分组，但低版本 MySQL 不行，得写完整表达式 - 索引对时间差计算无效——即使
start_time和end_time都有索引，TIMESTAMPDIFF(...)结果也无法走索引，大数据量时考虑预计算并持久化差值字段
SQL Server 的 DATEDIFF_BIG 是分水岭
SQL Server 2016+ 引入 DATEDIFF_BIG，解决老版 DATEDIFF 在毫秒/微秒级计算时的整数溢出问题。如果你的字段是 DATETIME2(7) 且跨度大（比如日志起止时间差几年），用普通 DATEDIFF(SECOND, ...) 可能报错 “Arithmetic overflow error”。
- 一律优先用
DATEDIFF_BIG(SECOND, start_time, end_time)，再除以区间长度取整，兼容性更稳 - 注意
DATEDIFF系列函数计算的是“边界跨越数”，不是精确经过时间。例如DATEDIFF(MONTH, '2023-01-31', '2023-02-28')返回 1，尽管实际只差 28 天 - 若需精确秒级差，且字段含纳秒精度，用
DATEADD反推再比对，或改用DATEDIFF_BIG(NANOSECOND, ...)后换算（但性能较差）
实际写的时候，先确认数据库类型和版本，再决定用哪个函数打底；区间逻辑越复杂，越建议把差值计算抽成子查询或 CTE，避免主查询里堆砌嵌套表达式。边界定义和 NULL 处理，往往比算法本身更容易出线上问题。
