SQL Server中截断时间到半小时的正确方法是：DATEADD(MINUTE, FLOOR(DATEDIFF(MINUTE, 0, access_time) / 30.0) * 30, 0)，先转为距1900-01-01的分钟数，再向下取整到最近30分钟倍数，最后还原为datetime。
用 DATEPART 和 FLOOR 截断时间到半小时（SQL Server）
SQL Server 没有原生的“向下取整到最近半小时”函数，得靠组合计算。核心思路是：把时间转成从某起点开始的分钟数 → 除以 30 取整 → 再乘回分钟数 → 转回 datetime。
常见错误是直接用 DATEPART(MINUTE, t) / 30，这会丢掉小时和日期信息，导致所有 9:15、10:15、11:15 全被归到同一组。
- 正确写法：
DATEADD(MINUTE, FLOOR(DATEDIFF(MINUTE, 0, access_time) / 30.0) * 30, 0)
-
DATEDIFF(MINUTE, 0, access_time)把时间转成距 SQL Server 零点（1900-01-01）的分钟数 - 除以
30.0（不是 30）确保得到浮点结果，FLOOR才能正确截断 - 再用
DATEADD把分钟数加回去，还原成 datetime 值
用 STRFTIME 实现半小时分组（SQLite）
SQLite 的 STRFTIME 支持格式化，但不支持直接按半小时向下取整，需借助整数运算。
容易踩的坑是误用 %H:%M 格式后字符串截断——比如把 '09:47' 截成 '09:30'，这在跨小时（如 09:59 → 10:00）时会出错。
- 安全做法：
STRFTIME('%Y-%m-%d %H:', access_time) || CAST((CAST(STRFTIME('%M', access_time) AS INTEGER) / 30) * 30 AS TEXT) - 更健壮的替代（推荐）：
STRFTIME('%Y-%m-%d %H:%M', access_time, '-' || (CAST(STRFTIME('%M', access_time) AS INTEGER) % 30) || ' minutes')—— 先减去多余的分钟数 - 注意：SQLite 时间函数对 null 敏感，
access_time为 null 时整行会被过滤，需提前处理
GROUP BY 中复用计算字段避免重复写表达式（通用技巧）
半小时分组表达式又长又易错，如果在 SELECT 和 GROUP BY 里各写一遍，不仅难维护，还可能因微小差异（比如一个用了 30.0 一个用了 30）导致逻辑不一致。
- PostgreSQL/MySQL 8.0+/SQL Server 支持子查询或 CTE：
SELECT half_hour, COUNT(*) FROM (SELECT ..., DATE_TRUNC('hour', access_time) + INTERVAL '30 min' * FLOOR(EXTRACT(MINUTE FROM access_time)/30) AS half_hour FROM logs) t GROUP BY half_hour - SQLite 不支持列别名用于
GROUP BY，必须重复表达式或用GROUP BY 1（按 SELECT 第一列位置） - 别依赖
GROUP BY自动推导：有些方言（如旧版 MySQL）允许SELECT *+ 简单GROUP BY，但半小时分组属于复杂表达式，必须显式写出
跨天聚合时注意时区与边界（生产环境关键点）
日志时间字段如果是 datetime 无时区，而服务器和应用部署在不同时区，半小时分组可能在凌晨出现“跳变”——比如北京时间 23:59 和 00:01 被分到不同半天，但实际是连续访问。
- 优先确认
access_time存储的是 UTC 还是本地时间；聚合前统一转换：AT TIME ZONE 'UTC'（SQL Server）、CONVERT_TZ（MySQL） - 半小时桶的起始点默认是 :00 和 :30，但业务可能要求从 :15/:45 开始（如监控系统采样点）。这时不能只改除数，要先偏移再计算：
DATEADD(MINUTE, -15, access_time)
再套用前面的半小时截断逻辑 - 索引有效性常被忽略：对原始
access_time建的索引，在使用上述表达式后基本失效；若高频查半小时聚合，考虑增加计算列并建索引（SQL Server 支持PERSISTED）
实际跑起来才发现，最耗时的往往不是写对表达式，而是验证分组边界是否真的一致——比如拿一条 2024-05-20 14:29:59 和一条 14:30:00 的数据，手动算它们该进哪个桶，再比对 SQL 结果。这个动作值得多做两次。
