date_trunc是时间分组首选，因其返回TIMESTAMP类型可走索引，而to_char返回文本无法利用索引；支持范围查询、天然有序、精度参数解析零开销；需注意时区、week/quarter起点及generate_series补全缺失日期。
直接用 date_trunc，别用 to_char 或字符串拼接做分组——前者能走索引，后者基本等于放弃性能。
为什么 date_trunc 是时间分组的首选
它把任意时间戳“对齐”到周期起点（比如把 '2026-04-12 19:23:00' 截成 '2026-04-12 00:00:00'），返回仍是 TIMESTAMP 类型，数据库能直接利用日期字段上的 B-tree 索引。而 to_char(order_date, 'YYYY-MM') 返回的是文本，每次都要计算、无法命中索引，百万级数据下慢几倍是常态。
- 截断后值可参与范围查询：
WHERE date_trunc('month', order_date) = '2026-04-01'能走索引 - 支持
GROUP BY直接分组，结果天然有序，不用额外ORDER BY - 精度参数是字符串字面量（
'day'、'hour'），不是变量，解析开销为零
date_trunc 常见精度陷阱与写法差异
不同精度对“起点”的定义不同，尤其 'week' 和 'quarter' 容易出错：
-
date_trunc('week', '2026-04-12')→'2026-04-06'（PostgreSQL 默认周一为每周第一天） -
date_trunc('quarter', '2026-04-12')→'2026-04-01'（不是 4 月 1 日？其实是：Q2 从 4 月开始，所以没错） -
date_trunc('month', '2026-04-01 00:00:00.123')→'2026-04-01 00:00:00'（毫秒被清零，但类型仍是TIMESTAMP） - 时区敏感：若字段是
TIMESTAMPTZ，date_trunc按当前会话时区截断；要固定时区，先用AT TIME ZONE转换：date_trunc('day', order_time AT TIME ZONE 'Asia/Shanghai')
和 generate_series 配合补全缺失日期
单纯 GROUP BY date_trunc('month', ...) 只会返回有数据的月份。要做完整月度报表（比如显示 2026 年前 4 个月，哪怕某月没订单也要显示 0），必须联查 generate_series：
SELECT
m.month,
COALESCE(t.total_sales, 0) AS total_sales
FROM generate_series('2026-01-01'::DATE, '2026-04-01'::DATE, '1 month') AS m(month)
LEFT JOIN (
SELECT
date_trunc('month', order_time)::DATE AS month,
SUM(amount) AS total_sales
FROM orders
WHERE order_time >= '2026-01-01'
GROUP BY date_trunc('month', order_time)
) t ON m.month = t.month;
-
generate_series的 start/stop 必须显式转成DATE或TIMESTAMP，否则类型推导可能失败 - 左表用
::DATE强制统一类型，避免隐式转换导致 JOIN 失败 - 子查询里
WHERE条件不能写成date_trunc('month', order_time) BETWEEN ...，否则索引失效；应改用原始字段范围过滤
生产环境必须检查的三件事
上线前漏掉任何一项，都可能导致报表数据错位或查询爆炸：
- 确认时间字段类型：是
TIMESTAMP还是TIMESTAMPTZ？后者在跨时区服务中行为更复杂 - 检查是否建了函数索引：如果高频按月分组，执行
CREATE INDEX idx_orders_month ON orders (date_trunc('month', order_time)); - 验证
date_trunc('week', ...)的起始日是否符合业务预期（PostgreSQL 默认周一，某些地区要求周日，需用EXTRACT(DOW FROM ...)手动调整）
最常被忽略的是时区处理——开发库用本地时间跑得通，上生产连上 UTC 时区的 RDS 就发现所有“今日数据”全偏了一天。别依赖默认，显式写清楚时区。
