用FLOOR+时间戳转换可实现任意分钟粒度分组，核心是将datetime转为秒级时间戳后除以目标间隔（如1800秒），FLOOR向下取整再还原为起始时间点，避免ROUND/CEIL导致的跨桶偏移；需注意时区对齐、TIMESTAMP/DATETIME差异及空桶补全，性能优化可借助函数索引或预计算字段。
用 FLOOR + 时间戳转换实现任意分钟粒度分组
直接对 datetime 字段 GROUP BY 无法按半小时切分，必须先将其映射到固定时间桶。核心思路是：把时间转为秒级时间戳（或分钟数），除以目标间隔（如 1800 秒 = 半小时），再用 FLOOR 向下取整，最后还原为起始时间点。
常见错误是用 ROUND 或 CEIL，会导致跨桶偏移（比如 09:29:59 被归到 09:30–10:00 桶，但 09:30:00 又被归到同一桶——看似没问题，可一旦有毫秒或时区偏差就错乱；FLOOR 才保证左闭右开语义稳定）。
以 MySQL 为例：
SELECT FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(event_time) / 1800) * 1800) AS half_hour, COUNT(*) FROM logs GROUP BY FLOOR(UNIX_TIMESTAMP(event_time) / 1800);
PostgreSQL 需换用 EXTRACT(EPOCH FROM ...)；SQL Server 则用 DATEDIFF(second, '1970-01-01', event_time)。
处理不同时区和 TIMESTAMP 类型陷阱
TIMESTAMP 在 MySQL 中自动转为 UTC 存储，但 UNIX_TIMESTAMP() 默认按会话时区解释输入值，容易导致分组漂移。若业务时间是北京时间（UTC+8），而数据库时区设为 +00:00，直接用 UNIX_TIMESTAMP(event_time) 会少算 8 小时。
稳妥做法是显式转换时区后再计算：
- MySQL 8.0+：用
CONVERT_TZ(event_time, '+00:00', '+08:00')统一为业务时区 - PostgreSQL：用
event_time AT TIME ZONE 'Asia/Shanghai' - 避免依赖系统默认时区，所有时间运算前先确认
event_time的逻辑时区含义
另一个坑是 DATETIME 和 TIMESTAMP 混用：前者无时区概念，后者有，但在 GROUP BY 表达式中若未显式对齐，可能因隐式转换丢失精度。
生成完整时间桶（含空桶）需要 LEFT JOIN 辅助表
原生 GROUP BY 只返回有数据的桶，但监控类场景常需补全 09:00–09:30、09:30–10:00 等连续区间，哪怕某段没数据也要显示 COUNT=0。
不能靠应用层拼接，得在 SQL 内完成。方法是构造一个时间序列辅助表（可用 CTE 或临时表）：
WITH time_buckets AS (
SELECT FROM_UNIXTIME(1717027200 + (n.n * 1800)) AS bucket_start
FROM (
SELECT 0 AS n UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 -- 扩展更多
) n
)
SELECT
b.bucket_start,
COALESCE(c.cnt, 0) AS count
FROM time_buckets b
LEFT JOIN (
SELECT
FROM_UNIXTIME(FLOOR(UNIX_TIMESTAMP(event_time) / 1800) * 1800) AS bucket_start,
COUNT(*) AS cnt
FROM logs
WHERE event_time >= '2024-05-30 00:00:00'
GROUP BY FLOOR(UNIX_TIMESTAMP(event_time) / 1800)
) c ON b.bucket_start = c.bucket_start;注意：辅助表的起始时间（如 1717027200）必须与业务查询时间范围对齐，否则会漏桶或冗余。
性能敏感场景慎用函数索引和分区裁剪
上述写法中 FLOOR(UNIX_TIMESTAMP(...)) 是非SARGable 表达式，无法利用 event_time 上的普通 B-tree 索引，全表扫描不可避免。当表超千万行时，响应会明显变慢。
优化路径有限，但可考虑：
- MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_event_halfhour ON logs ((FLOOR(UNIX_TIMESTAMP(event_time) / 1800))) - 若数据按天分区，务必在
WHERE中加上event_time >= '2024-05-30' AND event_time < '2024-05-31'，否则分区裁剪失效 - 高频查询可预计算字段（如新增
half_hour_bucket INT列，在写入时填充），用空间换查询稳定性
真正麻烦的是跨日边界——比如按 45 分钟分组，桶可能横跨两天，此时分区裁剪逻辑更脆弱，得反复验证执行计划里的 partitions 字段是否只扫了必要分区。
