直接用datepart或extract无法精准截断到半小时，因手动判断分钟区间会丢失跨小时边界；可靠方法是将时间转为距当日零点的总分钟数，整除30后乘回，实现向下取整对齐。
为什么直接用 DATEPART 或 EXTRACT 无法精准截断到半小时
常见误区是试图用 DATEPART(minute, time_col) 判断是否在 [0,29] 或 [30,59] 区间再手动拼接，但这样会丢失跨小时边界（比如 '14:59' 和 '15:01' 被分到不同半小时桶）。真正可靠的方式是把时间“向下取整”到最近的 30 分钟起点，即每小时的 :00 和 :30。这本质是时间轴上的整除对齐问题。
核心思路：把时间转成分钟数（从某一起点起），对 30 取模后减去余数，再转回时间类型。关键在于选对起点——通常以当天 '00:00' 为基准最稳妥。
- SQL Server 示例：
DATEADD(MINUTE, -(DATEPART(MINUTE, dt) % 30), dt)看似简洁，但遇到'15:00'时0 % 30 = 0没问题，而'15:29'得到'15:00'正确；但'15:30'会变成'15:30'（因为30 % 30 = 0），结果正确；不过该写法在跨天或含秒时易出错，不推荐直接用 - 更健壮做法：统一转为从当日零点起的总分钟数，再整除 30 后乘回 —— 这能规避所有边界情况
PostgreSQL 中用 FLOOR + EXTRACT 实现安全截断
PostgreSQL 没有内置的“向下取整到半小时”函数，但 EXTRACT(EPOCH FROM t) 可得秒级时间戳，除以 1800（30×60）再用 FLOOR 就能得到半小时序号，最后转回时间类型。
SELECT TO_TIMESTAMP(FLOOR(EXTRACT(EPOCH FROM event_time) / 1800) * 1800) AS half_hour_bucket, COUNT(*) FROM logs GROUP BY half_hour_bucket;
注意：TO_TIMESTAMP 默认按 UTC 解析，若数据是本地时区（如 'Asia/Shanghai'），需先用 AT TIME ZONE 标准化：
-
event_time AT TIME ZONE 'Asia/Shanghai'再参与计算 - 否则可能因夏令时或时区偏移导致同一物理半小时被拆成两个桶
MySQL 8.0+ 使用 UNIX_TIMESTAMP 和整数除法
MySQL 不支持 FLOOR 对时间直接运算，但可借助 UNIX_TIMESTAMP 转为整数秒，再用整数除法（div）实现向下取整：
SELECT FROM_UNIXTIME((UNIX_TIMESTAMP(event_time) DIV 1800) * 1800) AS half_hour_bucket, COUNT(*) FROM logs GROUP BY half_hour_bucket;
这个写法在 MySQL 中稳定，但要注意：
- 如果
event_time是DATETIME类型且含微秒，UNIX_TIMESTAMP会截断到秒，不影响半小时对齐 - 若字段是
TIMESTAMP类型且服务器时区设置混乱，结果可能意外偏移一小时 —— 建议显式用CONVERT_TZ(event_time, '+00:00', @@session.time_zone)统一时区
模运算截断的隐藏陷阱：时区、精度、NULL 处理
无论哪种数据库，只要原始时间字段存在 NULL、微秒精度、或未标准化时区，模运算截断就会失效或产生空桶。
- NULL 值会导致整个分组被跳过，聚合结果缺失 —— 必须加
WHERE event_time IS NOT NULL显式过滤 - SQL Server 的
DATETIME2(7)含纳秒，直接DATEPART(MINUTE, ...)会四舍五入到分钟，造成偏差；应先CAST(... AS DATETIME2(0))截断精度 - 所有方案都假设时间值已按业务所需时区存储；若数据库存 UTC、但业务看东八区，则必须在截断前转换，不能依赖客户端补正
最易被忽略的是：半小时桶的标签时间（如 '14:00'）仅代表该桶起点，不代表数据实际发生时间范围 —— 它覆盖的是 [14:00, 14:30) 左闭右开区间。这点在做环比或与外部系统对齐时，必须和对方确认语义一致。
