SQL如何按特定时间间隔分组查询：日期函数与数学运算
先明确一个核心事实：SQL本身并不直接支持“每15分钟一组”这类动态间隔分组。要实现它，得靠日期函数配合数学运算，把连续的时间映射成离散的整数，再按整数分组。说白了，就是把时间转成秒级时间戳，除以间隔秒数后取整，最后再还原回时间起点。
MySQL不支持直接按15分钟动态分组，需用UNIX_TIMESTAMP转秒级时间戳，减基准时间（如当日0点），除以900后FLOOR取整再还原；时区未对齐是分组错位主因。
MySQL里用DATE_SUB和FLOOR做时间切片分组
直接说结论：SQL本身不支持“每15分钟一组”这种动态间隔分组，得靠日期函数+数学运算把时间映射成离散整数，再按整数分组。核心思路是把时间转成秒级时间戳，除以间隔秒数取整，再还原回时间起点。
一个常见的误区是直接用DATE_FORMAT(dt, ‘%Y-%m-%d %H:%i’)去截断分钟。这么做，每小时只能切出00、15、30、45这四个固定点。但现实场景往往更复杂：数据可能跨天、跨时区，或者需要从某个特定的起始时间（比如当天0点）开始对齐——这时候，DATE_FORMAT就完全失效了。
- 正确做法：使用
UNIX_TIMESTAMP(dt)将时间转为整数时间戳，减去一个明确的基准时间戳（例如当天0点），再除以间隔秒数（比如15分钟就是15×60=900），最后用FLOOR函数取整。 - 基准时间要显式计算：别图省事依赖
NOW()，否则在凌晨跑批处理时，很容易因为跨天而导致分组错位。 - MySQL 8.0+ 的变通：虽然提供了
DATE_TRUNC函数，但它只支持到年、月、日、时、分等固定单位，对于任意秒级的间隔（比如每7分钟），依然需要手动计算。
PostgreSQL用width_bucket和generate_series更直观
相比之下，PostgreSQL的原生支持就显得友好一些。它提供了width_bucket这类区间分桶函数，思路比MySQL少绕几个弯。不过要注意：width_bucket返回的是桶的序号，而不是具体的时间值。如果想还原成可读的时间范围，还得配合generate_series或进行额外的计算。
一个典型场景是绘制监控折线图，需要补全那些没有数据的时间段（比如某15分钟内记录数为0，但图表上仍需显示）。这时，光靠GROUP BY是不够的，得先生成一个完整的时间序列，再通过LEFT JOIN去关联原始数据。
- 分桶计算：例如
width_bucket(EXTRACT(EPOCH FROM ts), 0, EXTRACT(EPOCH FROM NOW()), 96)，这会把当天总秒数分成96段（24小时×4）。但这里的起始点是0秒，而非当天的0点，因此通常需要先减去DATE_PART(‘epoch’, CURRENT_DATE)来对齐。 - 生成序列的要点：使用
generate_series生成时间点时，务必明确指定timezone参数。否则，UTC时间和本地时间混用，极易导致分组出现难以察觉的偏移。 - 时区类型陷阱：如果表中的
ts字段是timestamptz类型，那么EXTRACT(EPOCH FROM ts)会自动转为UTC时间戳；但如果它是timestamp类型，则会按服务器时区来解释——这个细节，往往是踩坑的重灾区。
SQLite里没有UNIX_TIMESTAMP，得用julianday硬算
SQLite的处境更“原始”一些，连标准的时间函数都欠缺。它主要依赖julianday函数，该函数返回的是儒略日（一个带小数的浮点数，单位是天）。想实现每30分钟分组，就得先把时间差值换算成以天为单位的小数，再乘以（24×2）=48，最后通过CAST(… AS INTEGER)来取整。
来看一个按每30分钟分组统计的示例，起始点设为当天0点：
SELECT
datetime(julianday('now', 'start of day') + CAST((julianday(ts) - julianday('now', 'start of day')) * 48 AS INTEGER) / 48.0) AS interval_start,
COUNT(*)
FROM logs
GROUP BY interval_start;
这个写法看起来确实有些绕，但实属无奈——SQLite没有FLOOR，也没有TRUNC。CAST(x AS INTEGER)对正数等价于向下取整，但对负数会向零截断。因此，必须确保所有时间都在当天之内（即条件ts >= ‘now’, ‘start of day’）。
- 处理跨天数据：如果数据跨越了多天，需要先用
date(ts)按日期分组，再在每一天内部进行时间间隔计算。否则，julianday的差值计算可能会溢出精度。 - 精度限制：
julianday的精度大约在毫秒级。对于高频写入的场景（比如每秒上千条），同一分钟内的多条记录可能因为浮点数舍入误差而被分到不同的桶里——这并非逻辑错误，而是由底层精度限制导致的。
所有数据库都绕不开的时区陷阱
时间分组出现错位，十有八九是时区没对齐惹的祸。即便你在代码里明确写了AT TIME ZONE ‘Asia/Shanghai’，也要警惕：底层存储的数据类型是否匹配？查询时是否发生了隐式的时区转换？
- MySQL的时区“分裂”：
DATETIME类型不存储时区信息，而TIMESTAMP类型则存储为UTC时间。如果在GROUP BY时混用了返回TIMESTAMP的NOW()和DATETIME类型的字段dt，MySQL会按照系统时区进行隐式转换，结果往往不可控。 - PostgreSQL的类型转换坑：将
timestamptz类型转换为timestamp类型时，时区信息会被丢弃。如果再用这个结果去计算EXTRACT，就等于默认按UTC处理了，而你的业务逻辑很可能期望的是东八区时间。 - 最稳妥的策略：统一使用UTC时间进行存储，所有分组计算也基于UTC时间戳来完成。仅在最终的数据展示层，再根据需求转换为本地时区。尽量避免在SQL分组逻辑中直接进行
AT TIME ZONE转换，那样不仅性能较差，还极易引入错误。
真正棘手的问题往往不是语法怎么写，而是当你查出的分组结果里，第一组时间显示为“2024-05-01 00:13:00”时——这明确告诉你，基准时间没有对齐，或者时区转换在某个环节悄悄发生了。这类问题通常不会抛出错误，只会让数据看起来“差不多”，但关键时段的统计偏差，却会像滚雪球一样越来越大。
