postgresql分区表delete无法走全局索引，因优化器仅在where条件精确匹配分区键时才执行分区裁剪；若含函数、隐式转换或分区键未参与过滤，将扫描所有子分区导致性能骤降。
分区表上的 DELETE 为什么不能直接走全局索引？
PostgreSQL 16 的原生声明式分区表（PARTITION BY RANGE/LIST/HASH）在执行 DELETE 时，优化器会自动裁剪（partition pruning）——但仅限于 WHERE 条件能精确匹配分区键值或范围。如果条件里用了函数、隐式转换、或分区键未参与过滤（比如只查 status = 'deleted' 而分区键是 created_at），就会退化为扫描所有子分区，性能断崖式下跌。
常见错误现象：EXPLAIN 显示多个 Append 节点下都出现 Seq Scan，且 Filter 行里反复出现分区键无关的谓词。
- 确保 WHERE 中分区键字段直接参与比较，例如
WHERE created_at ，而不是 <code>WHERE date_trunc('month', created_at) = '2024-12-01' - 避免对分区键字段做任何表达式操作：不加
lower()、不转类型（如created_at::date）、不套子查询 - 若必须用非分区键字段过滤，先建局部索引（
CREATE INDEX ... WHERE）并确认其谓词与 DELETE 条件字面量完全一致
DELETE 分区数据最快的方式不是 DELETE，而是 DROP PARTITION
如果你要删的是整个月/年的历史分区（比如日志表按月分区，现在要清理 2024 年前所有数据），DROP TABLE 对应的分区表比 DELETE 快几个数量级——因为它是元数据操作，不触碰数据页、不写 WAL、不触发触发器、也不需要 VACUUM。
实操前提是：该分区没有被其他对象依赖（如外键指向它、物化视图引用它、或正在被查询中使用 ONLY 限定）。否则会报错 ERROR: cannot drop partition "xxx" because it is referenced by a foreign key。
- 查出目标分区名：
SELECT inhrelid::regclass FROM pg_inherits WHERE inhparent = 'your_parent_table'::regclass AND inhrelid::text LIKE '%2023%'; - 安全删除前先解除外键（如有）：
ALTER TABLE child_table DROP CONSTRAINT fk_name; - 执行：
DROP TABLE IF EXISTS your_parent_table_2023_01;（注意：名称需与实际分区名严格一致） - 别忘了后续
VACUUM ANALYZE your_parent_table;更新父表统计信息
带级联的 DELETE 在分区表上仍需分批，不能靠分区自动提速
即使你删的是单个分区内的数据（比如 DELETE FROM logs_2024_06 WHERE status = 'error'），只要涉及 ON DELETE CASCADE 关联子表，且子表本身未分区或未按相同逻辑分区，优化器就无法跨表裁剪。此时级联链路仍会遍历全部关联行，大删照样锁表、打满 WAL。
关键事实：DELETE ... CASCADE 不会“继承”父表的分区裁剪能力；每个被级联的子表都独立评估执行计划。
- 先确认子表是否也做了相同分区策略（如按
log_id哈希分区），否则级联路径仍是瓶颈 - 对主分区表仍要用
WITH batch AS (...) DELETE ... IN (SELECT)模式分批，每次限制LIMIT 5000以内 - 若子表无索引支撑级联条件（如外键列没索引），
DELETE会触发子表全扫——务必补上：CREATE INDEX ON child_table (parent_id); - 避免在事务中连续删多个分区：每个
DROP PARTITION是独立事务，但批量DELETE跨分区必须手动控制 commit 频率
局部索引 + 分区裁剪组合失效的三个典型信号
你以为建了 CREATE INDEX idx_logs_error ON logs_2024_06 (user_id) WHERE status = 'error' 就万事大吉？不一定。PostgreSQL 16 的优化器在分区 + 局部索引混合场景下极其敏感，稍有不匹配就弃用索引。
检查 EXPLAIN (ANALYZE, BUFFERS) 输出时盯紧这三点：
-
Index Cond为空，但Filter里有你的局部索引字段 → 统计信息陈旧，立刻跑ANALYZE logs_2024_06; - 看到
Index Scan using idx_logs_error on logs_2024_06，但Rows Removed by Filter占比超 80% → 局部索引谓词太宽（比如建的是WHERE status IN ('error', 'failed')，但 DELETE 只删'error'），重建索引收窄谓词 - 索引名根本没出现在执行计划里 → 检查
pg_index.indisvalid是否为t，建索引中途失败会导致indisvalid = f，此时需DROP INDEX重来
最易被忽略的一点：分区表的局部索引必须在每个目标子分区上单独创建，父表上建的局部索引不会自动下推到子分区。
