date_trunc('second', ts)在千万级表上变慢是因为无法走索引且每行需计算，导致全表扫描、GROUP BY哈希膨胀及内存压力增大；替代方案是用时间范围对齐或created_at::timestamp(0)。
直接用 date_trunc('second', ts) 分组在千万级表上会明显变慢，不是语法错，是执行计划崩了——函数无法走索引，且每行都要计算。
为什么 date_trunc('second', ...) 在大表上很慢
PostgreSQL 对 date_trunc() 的结果不自动建立函数索引，即使你对原始时间戳字段建了 B-tree 索引，查询时仍要全表扫描并逐行计算截断值。尤其当分组字段本身无业务意义（比如只为了看每秒请求数），却强制生成大量唯一值（秒级精度下，一天就有 86400 个可能分组），会导致：
– GROUP BY 哈希表膨胀严重
– 排序和聚合内存压力陡增
– 并行 worker 间数据重分布开销放大
- 实测：某 1200 万行日志表，
GROUP BY date_trunc('second', created_at)耗时 8.2s；等价的GROUP BY created_at::timestamp(0)（带 cast）快 3 倍，但依然没索引加速 - 注意：
timestamp(0)是秒级精度类型转换，不是截断函数，它不改变值逻辑，但 PostgreSQL 可能更易优化 - 如果只是做监控类秒级统计，通常不需要精确到“某秒的起始时刻”，而是“该秒内发生的事件数”——这时用范围对齐比截断更稳
替代方案：用 created_at >= '...' AND created_at 手动切片
绕过函数、让 planner 直接走索引的最可靠方式。适用于你知道分组边界（如每秒、每 5 秒）且能接受固定窗口（非自然秒对齐）的场景。
- 例如按每 5 秒统计：用
(EXTRACT(EPOCH FROM created_at) / 5)::int * 5算出时间片起点，再转回 timestamp 构造 WHERE 条件 - 更推荐写成子查询或 CTE 预算边界，避免在 WHERE 中重复计算：
WITH buckets AS ( SELECT generate_series( '2026-04-12 00:00:00'::timestamp, '2026-04-12 23:59:59'::timestamp, '5 seconds'::interval ) AS bucket_start ) SELECT b.bucket_start, COUNT(*) FROM buckets b LEFT JOIN events e ON e.created_at >= b.bucket_start AND e.created_at < b.bucket_start + '5 seconds'::interval GROUP BY b.bucket_start; - 关键点：WHERE 中的
>=和能命中 <code>created_at上的普通 B-tree 索引；generate_series 生成的 bucket 数可控，不会爆炸
真要保留 date_trunc，必须加函数索引
否则任何基于它的 GROUP BY 都是自找麻烦。函数索引不是可选项，是硬性前提。
- 建索引语句必须和查询中完全一致：
CREATE INDEX idx_events_ts_second ON events (date_trunc('second', created_at)); - 验证是否生效：用
EXPLAIN看执行计划里有没有 Index Scan on idx_events_ts_second；如果出现 Bitmap Heap Scan 或 Seq Scan，说明没用上 - 注意：函数索引只对相同参数有效。写成
date_trunc('sec', ...)或date_trunc('seconds', ...)（多 s）都会导致索引失效 - 函数索引会增加写入开销（INSERT/UPDATE 时也要维护），高频写入表慎用；若只读或低频更新，这是最干净的解法
真正卡住性能的从来不是“怎么写 SQL”，而是“有没有让数据库用上索引”。date_trunc 很方便，但方便的前提是你已经为它铺好了索引路——否则宁可用显式范围 + generate_series 控制节奏。
