PostgreSQL 分区表什么时候变慢：分区裁剪失效、730 个分区规划 65 ms、DEFAULT 分区挡住新分区实测

脚本对每条查询跑一次 EXPLAIN (ANALYZE, BUFFERS)，再跑 2 次只取 Planning / Execution Time，并统计计划里各分区扫描节点“执行了”和“never executed”的个数。完整 21 行结果在样例 CSV 里。

先看裁剪正常的情况：WHERE created_at >= '2026-09-01' AND created_at < '2026-09-08'，不分区表走 Bitmap Heap Scan 读 27412 个块，50–108 ms；按月分区只剩 ev_m_202609 一个分区，15–19 ms；按天分区剩 7 个分区，8.3–9.5 ms，返回都是 42014 行。

然后我把同样的意图换了 3 种常见写法。date_trunc('month', created_at) = '2026-09-01'、created_at::date = '2026-09-03'、to_char(created_at, 'YYYY-MM') = '2026-09'，计划里 24 个分区一个不少，分别 146–217 ms、95–104 ms、282–296 ms。裁剪只认“分区键 运算符 常量/参数”这种形式，表达式包住分区键以后，规划器无法据此排除分区，而分区索引建在 created_at 上，这几个表达式也用不上它。

改成半开区间 created_at >= '2026-09-03' AND created_at < '2026-09-04'，只剩 1 个分区，0.93–0.95 ms，比 ::date 写法快约 100 倍。ORM 或报表工具自动生成的 SQL 最容易出这个问题，排查时直接看计划里有几个 Seq Scan / Index Scan on 分区名就行。

WHERE created_at >= CURRENT_DATE - 7 和 created_at >= now() - interval '7 days'，在 ev_m 上都只执行了 3 个分区（10 月以及还没有数据的 11、12 月），计划里有一行 Subplans Removed: 21。这一行我一开始以为只有 EXPLAIN ANALYZE 才有，实际上普通 EXPLAIN 里也会显示，因为这一步裁剪发生在执行器初始化阶段，而 EXPLAIN 也会走到这一步。

代价在规划：这两种写法规划 2.4–3.7 ms，常量写法 0.7–0.9 ms。原因是规划器不能在计划期用稳定函数的值，只能先给 24 个分区都生成计划，再在启动时删掉 21 个。分区数少时影响不大；分区数上千、QPS 又高时，可以在应用里算好日期再以常量或参数传入。

WHERE user_id = 4242 ORDER BY created_at DESC LIMIT 20，不带分区键。不分区表一个 (user_id, created_at) 索引搞定，规划 0.38–0.46 ms、执行 0.15–0.27 ms。按月分区规划 2.0–2.7 ms，有序 Append 从最新的分区往回找，13 个分区执行到、11 个 never executed。按天分区规划 61–69 ms、执行 7.1–10.3 ms，393 个分区被执行到、337 个 never executed。

加一个 created_at >= '2026-10-01' 的下限，按天分区只剩 92 个分区参与规划（10 月 1 日到 12 月 31 日，包括还没数据的未来分区），规划降到 10.9–12.0 ms、执行 1.0–1.1 ms。还有个细节：未来分区建得越早，这类查询要规划的空分区越多，本次 69 个空的叶子分区也在规划范围里。

作者在游戏行业做过几千亿条日志的分区设计，那个量级不分区每天都写不进去，所以要权衡的从来不是分不分，而是按什么粒度分、查询是不是都带分区键。业务里大量查询不带分区键时，按月或更粗的粒度往往更合适，本次 730 个日分区就是反例。

PREPARE s(timestamp, timestamp) AS SELECT count(*) FROM ev_d WHERE created_at >= $1 AND created_at < $2，参数是 9 月 1 日到 8 日。plan_cache_mode = force_custom_plan 时每次按实际参数规划，第一次 5.1 ms，第二次 0.35 ms（分区元数据已在缓存里），执行 7.7–9.5 ms，走 Seq Scan。

force_generic_plan 时，第一次要给 730 个分区做一份不依赖参数的计划，规划 55.6 ms，执行时 Subplans Removed: 723；之后复用计划，规划 0.14 ms。另一个差别是行数：generic plan 估计 20058 行，实际 42014 行，选了 Index Only Scan；查询更复杂、有 JOIN 时，这种估算偏差可能把后面的连接方式带偏。默认 auto 会先用 5 次 custom plan 再决定，连接池里每个新连接都会重新经历一次首次规划。

在分区表 ev_m 上 ADD PRIMARY KEY (id)，报 ERROR: unique constraint on partitioned table must include all partitioning columns，DETAIL 写明 PRIMARY KEY constraint on table "ev_m" lacks column "created_at"。分区表的唯一性只能在每个分区内保证，所以主键要改成 (id, created_at)，400 万行建了 808 ms。全局唯一的 id 要靠序列或者业务侧保证。

DEFAULT 分区那个坑更隐蔽。ev_def 只建了 10 月分区和 DEFAULT，11 月分区忘了建，于是 3 行 11 月的数据进了 DEFAULT（另有 200000 行没有对应分区的老数据也在里面）。之后补建 11 月分区，报 ERROR: updated partition constraint for default partition "ev_def_default" would be violated by some row。把这 3 行挪走（DELETE 10.2 ms）后再建，10.3 ms 成功，这一步要扫描 DEFAULT 分区确认没有冲突的行，DEFAULT 越大越慢。

我的做法：提前建好未来 2–3 个周期的分区；如果保留 DEFAULT，就每天看一次里面有没有数据，有就告警。文末只读 SQL 第 3、4 段就是做这件事的。

把一张 181083 行的普通表 ATTACH 成分区，不带约束时要全表扫描验证分区约束，12.0 ms；先 ADD CONSTRAINT ck CHECK (created_at >= '2026-09-01' AND created_at < '2026-10-01')（12.9 ms），再 ATTACH 只要 0.44 ms。总耗时差不多，但验证扫描挪到了 ATTACH 之前、这张表还没挂上分区树的时候，ATTACH 本身只要 0.44 ms。本次表小，差别只有十几毫秒，表越大越值得这样做。如果这张表在 ATTACH 前还有读写，可以用 ADD CONSTRAINT … NOT VALID 再 VALIDATE CONSTRAINT 降低锁级别，这条路径本次没有测。

删 2025 年 1 月的 188215 行：在不分区的 ev_flat 上 DELETE 用了 254.6 ms，产生 10 MB WAL，表文件 355 MB，删完和 VACUUM（544.3 ms）之后都还是 355 MB，空间只是在表内可复用。按月分区上 DETACH PARTITION … CONCURRENTLY 2.4 ms + DROP TABLE 11.2 ms，WAL 只有 14 kB，空间立刻还给文件系统。按天分区上 DETACH（非 CONCURRENTLY）4.6 ms + DROP 2.9 ms。

实验脚本会建删库，只能在测试实例跑。到自己的库上，先跑这份只读体检 SQL（8 段，只有 SELECT，已过站内只读守卫测试）：版本与 enable_partition_pruning、plan_cache_mode 等参数；每张分区表的分区方式、分区键、分区数、有没有 DEFAULT、总大小；DEFAULT 分区里的估算行数；每张 range 分区表最新 3 个分区的边界（看未来分区建好没有）；叶子分区数和空分区数；分区表上的主键 / 唯一约束；分区索引是否完整（indisvalid）；最大的 10 个叶子分区。

在实验库上跑的结果：ev_d 729 个分区（P9 删掉了 1 个）、69 个空分区；ev_def 的 DEFAULT 分区估算 200000 行、18 MB，会被第 3 段列出来；最新分区边界到 2026-12-31。注意 reltuples 是统计估算，刚批量写入、还没 ANALYZE 的分区可能显示 0 或 -1。