DATE_TRUNC不是位对齐而是按指定单位截断到起始时刻，如'2024-05-12 14:37:22'截断到小时得'2024-05-12 14:00:00'；支持microsecond至millennium共13种大小写敏感的粒度字符串。
DATE_TRUNC 是什么，它真能“按位对齐”时间戳？
不能。这是个常见误解——DATE_TRUNC 不是对时间戳做二进制或数值“位对齐”，而是按指定时间单位（如 'hour'、'day'）**截断到该单位的起始时刻**。比如把 '2024-05-12 14:37:22' 截断到小时，结果是 '2024-05-12 14:00:00'，不是“对齐最低有效位”，而是“归零更小单位”。理解这点能避免在时序分析中误用。
哪些时间粒度被支持？参数大小写敏感吗？
PostgreSQL 支持的粒度包括：'microsecond'、'millisecond'、'second'、'minute'、'hour'、'day'、'week'、'month'、'quarter'、'year'、'decade'、'century'、'millennium'。注意：DATE_TRUNC 的第一个参数（粒度）**必须是字符串字面量，且区分大小写**——写成 'HOUR' 或 'Hour' 会报错：ERROR: invalid value for parameter "precision"（实际错误信息因版本略有差异，但本质是不识别）。
-
DATE_TRUNC('hour', '2024-05-12 14:37:22'::timestamptz)→'2024-05-12 14:00:00+00' -
DATE_TRUNC('week', '2024-05-12'::date)→'2024-05-06'（周一为一周起点） - 不支持自定义周期（如“每15分钟”），想实现需结合
EXTRACT+ 算术运算
和 GROUP BY 配合时，为什么有时结果不符合预期？
因为 DATE_TRUNC 返回的是带时区的时间类型（timestamptz 或 timestamp），而 GROUP BY 对值完全相等才合并。常见陷阱：
- 输入列是
timestamptz，但未显式指定时区上下文，导致不同记录被截断到不同 UTC 时间点 - 混用
DATE_TRUNC('day', col)和col::date：前者保留时区信息并归零时间部分，后者直接转为本地日期，二者在跨时区场景下可能分组不一致 - 聚合前未用
AT TIME ZONE标准化：例如统计“北京时间每天订单量”，应先写DATE_TRUNC('day', col AT TIME ZONE 'Asia/Shanghai')，而不是直接截断原始timestamptz
性能影响：索引能用上吗？
直接在 WHERE 或 JOIN 条件中使用 DATE_TRUNC('hour', ts_col) 通常无法利用 ts_col 上的 B-tree 索引，因为表达式不可索引（除非建函数索引）。解决办法：
- 建函数索引：
CREATE INDEX idx_events_hour ON events (DATE_TRUNC('hour', created_at)); - 改写查询条件为范围扫描（更高效）：
created_at >= '2024-05-12 14:00:00' AND created_at ，这样可走原生索引 - 注意：函数索引需与查询中使用的粒度、时区完全一致，否则不命中
真正容易被忽略的是时区处理——DATE_TRUNC 本身不转换时区，只截断；如果原始数据存的是 UTC，但业务逻辑按本地日历统计，漏掉 AT TIME ZONE 就会导致分组偏移整整一天。
