mergeappend未走索引扫描的根本原因是子分区缺少覆盖排序字段的索引，主表索引不继承，且排序字段须为分区键或索引最左前缀列；需为每个子分区显式创建b-tree或brin索引，并确保order by与索引列完全一致。
MergeAppend 为什么没走索引扫描？
PostgreSQL 在分区表上执行 MergeAppend 时，常出现“本该用索引却退化为全表扫描”的情况。根本原因不是分区本身有问题，而是子分区缺少对应索引，或索引未覆盖排序字段。比如查询 SELECT * FROM log_data WHERE created_at > '2023-01-01' ORDER BY created_at，若每个子分区（如 log_data_202301）没建 created_at 索引，优化器就无法保证各分区数据已按该字段有序，只能退回到 Append + Sort——先扫所有匹配分区，再全局排序。
- 必须为每个子分区单独创建索引，主表上建的索引不会自动继承到子分区（即使用了
PARTITION OF） - 排序字段必须是分区键，或至少是子分区索引的**最左前缀列**；否则
MergeAppend无法合并各分区已有序的结果流 - 如果分区键是
created_at，但查询条件是WHERE status = 'active'，那即使有status索引，MergeAppend也大概率不会启用，因为无法保证各分区输出顺序一致
如何验证 MergeAppend 是否真正生效？
别只看执行计划里有没有 MergeAppend 节点，重点看它下面是否出现 Index Scan 或 Index Only Scan，以及是否带 Sort Key。运行 EXPLAIN (ANALYZE, BUFFERS) SELECT ... ORDER BY ... 后检查：
- 节点层级中是否存在
Merge Append→ 每个子分区下是Index Scan using xxx_idx on log_data_202301 -
Sort Key必须与ORDER BY字段完全一致，且不能出现Sort Method: external merge Disk（说明仍需磁盘排序，MergeAppend失效） - 各子分区的
Actual Rows应明显少于总表行数，证明分区剪枝（Partition Pruning）成功
PostgreSQL 17 的 MergeAppend cost 修复对实际查询的影响
PG 17 修正了 MergeAppend 的代价估算 bug：旧版本高估了需要排序的数据量，导致优化器倾向选择更“保守”的 Append + Sort；新版本能更准确识别“各分区已有索引、数据天然有序”这一事实，从而更愿意选用 MergeAppend。但这不意味着升级后自动生效——你仍得手动补全索引。
- 升级 PG 17 后，务必重跑
ANALYZE更新统计信息，否则优化器可能沿用旧的行数估算 - 若查询仍选错计划，可用
SET enable_sort = off强制禁用Sort节点，观察是否触发MergeAppend，反向验证是否真因 cost 误判 - 注意：PG 17 并未修复“继承表无索引继承”这个底层限制，子分区索引仍需显式创建
容易被忽略的索引细节：BRIN vs B-tree
对时间序列类分区表（如日志、订单），在子分区上建 B-tree 索引虽有效，但空间开销大；而 BRIN 索引更适合——它只记录每个数据块的 min/max 值，在范围查询 + 分区剪枝双重过滤下，性能接近 B-tree，体积却小几个数量级。
- 建法：
CREATE INDEX idx_created_at_brin ON log_data_202301 USING BRIN (created_at) - 适用前提：数据写入严格按分区键单调递增（如时间戳），否则 BRIN 效果骤降
-
MergeAppend能正常使用 BRIN 索引完成有序扫描，但前提是ORDER BY字段与 BRIN 列完全一致
真正卡住 MergeAppend 的从来不是语法或版本，而是子分区索引缺失、排序字段与索引结构不匹配、或者误以为主表索引会自动下推——这些地方一漏，前面所有配置都白搭。
