需用date_trunc或extract对时间分组，避免原始时间粒度过细；注意时区转换、空值与异常值处理；可建生成列提升性能；自定义周期建议应用层预处理。
用 DATE_TRUNC 或 EXTRACT 实现时间段对齐分组
直接按原始时间字段 GROUP BY 会把每秒/毫秒都当独立组，根本没法看趋势。得先把时间“掰成块”——比如按小时、按天、按15分钟切。不同数据库语法有差异：DATE_TRUNC('hour', created_at)（PostgreSQL / BigQuery）最直观；MySQL 得用 DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')；SQLite 用 strftime('%Y-%m-%d %H:00:00', created_at)。注意：别用 ROUND(UNIX_TIMESTAMP(created_at) / 3600) 这类算术截断，跨时区或夏令时会错位。
计算均值前必须确认数值字段是否含空值和异常值
AVG() 默认自动忽略 NULL，但不会过滤掉明显离谱的脏数据（比如响应时间字段里混进一个 9999999）。先跑一遍：SELECT MIN(duration), MAX(duration), COUNT(*) FILTER (WHERE duration 300000) FROM events（PostgreSQL）或用 CASE WHEN 统计异常数量。如果异常比例高，得在 AVG() 外层套条件：AVG(CASE WHEN duration BETWEEN 100 AND 30000 THEN duration END)，否则均值会被严重拉偏。
避免因时区导致分组错乱
数据库服务器时区、连接会话时区、业务逻辑期望时区三者不一致时，DATE_TRUNC 结果可能和预期对不上。比如你想要北京时间每小时统计，但数据库是 UTC 时区，直接 DATE_TRUNC('hour', event_time) 会按 UTC 小时切。解决方法只有两个：AT TIME ZONE 'Asia/Shanghai'（PostgreSQL），或先把字段转成目标时区再截断：DATE_TRUNC('hour', event_time AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai')。MySQL 没原生时区转换函数，得靠 CONVERT_TZ(event_time, '+00:00', '+08:00')，且确保系统时区表已加载。
小时间隔下聚合性能差？试试物化分组字段
每次查都实时算 DATE_TRUNC('hour', created_at)，索引用不上，大数据量时很慢。如果查询模式固定（比如总要按小时看均值），建一个生成列：ALTER TABLE events ADD COLUMN hour_bucket TIMESTAMP GENERATED ALWAYS AS (DATE_TRUNC('hour', created_at)) STORED（PostgreSQL 12+），然后给这个列加索引。MySQL 5.7+ 用 GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')) STORED。注意：生成列不能直接用于分区，但能显著加速 WHERE hour_bucket BETWEEN ... 类查询。
真正麻烦的是“自定义周期”，比如每周三上午 9 点到下周三上午 9 点为一组——这种没法靠内置函数一步到位，得用 created_at - INTERVAL '3 days' - INTERVAL (EXTRACT(DOW FROM created_at) + 4) % 7 DAY 这类偏移推算，稍不留神就差一天。这种场景建议在应用层预处理时间戳，数据库只负责简单聚合。
