局部索引能显著加速特定条件的DELETE，但前提是DELETE的WHERE条件与索引谓词字面量完全匹配且为子集关系；不匹配则索引失效，常见原因包括谓词不一致、隐式转换、统计信息陈旧或索引无效。
局部索引（Partial Index）在 PostgreSQL 16 中确实能显著加速特定条件的 DELETE，但前提是你的 WHERE 条件与索引的谓词完全匹配——不匹配就白建。
局部索引必须精确覆盖 DELETE 的 WHERE 条件
局部索引只存储满足其 WHERE 谓词的行，优化器只有在 DELETE 的条件能被该谓词“完全包含”时才会使用它。比如你建了：CREATE INDEX idx_orders_pending ON orders (user_id, created_at) WHERE status = 'pending'
那么只有 DELETE FROM orders WHERE status = 'pending' AND user_id = 123 这类语句才可能走这个索引；如果写成 status IN ('pending', 'failed') 或 status = 'PENDING'（大小写不一致），索引就失效。
- 谓词必须字面量一致：
WHERE status = 'pending'≠WHERE lower(status) = 'pending' - 不能有隐式转换：字符串字段和数字比较（如
status = 0）会跳过局部索引 - 复合条件中，局部索引的谓词应是 DELETE 条件的“子集”，而非交集或超集
为什么 EXPLAIN 显示没走局部索引？常见原因
执行 EXPLAIN (ANALYZE, BUFFERS) DELETE FROM ... 后发现还是 Seq Scan，别急着重建索引，先查这三件事：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
-
Rows Removed by Filter远大于Rows Removed by Index Recheck：说明索引虽被用了，但过滤能力弱，大量回表后又被 WHERE 剩余条件筛掉——这时要检查局部索引谓词是否太宽，或联合列顺序是否错 -
Index Cond为空，Filter里却有你的关键字段：代表优化器认为走索引不如全扫，大概率是统计信息陈旧，运行ANALYZE orders再试 - 局部索引没出现在
Index Scan行里：确认该索引是否被pg_index.indisvalid标记为有效（建索引中途失败会导致 invalid）
DELETE 分批 + 局部索引的实操组合
对高频删、低比例命中（比如只删 0.1% 的 pending 订单）的场景，局部索引配合分批删效果最好。直接 DELETE WHERE status = 'pending' 可能锁表太久，而局部索引让每次分批都能快速定位目标块：
- 先用局部索引快速找出一批主键：
SELECT id FROM orders WHERE status = 'pending' ORDER BY id LIMIT 5000 - 再按主键删：
DELETE FROM orders WHERE id IN (SELECT id FROM ...)—— 这里IN子查询能复用局部索引，且避免大事务 - 注意：不要用
OFFSET分页删（性能随 offset 增长恶化），改用 where id > last_id 的游标方式
局部索引不是银弹——它只加速“恰好命中谓词”的 DELETE；建之前务必确认该条件在业务中真实高频、且值域稳定。一旦业务逻辑变更（比如新增 status = 'retry' 也要进报表），局部索引就得重审或补建，否则反而拖慢整体写入性能。
