partial index 的 where 条件必须是 immutable 表达式，禁止使用 now()、current_date 等 volatile/stable 函数；查询需显式包含该条件才能命中索引；虽节省存储但写入开销与普通索引相同。
Partial index 的 WHERE 条件必须是确定性表达式
postgresql 允许在 CREATE INDEX 里加 WHERE 子句，但这个条件不能含任何运行时才确定值的元素。比如 WHERE created_at > NOW() - INTERVAL '7 days' 是非法的——NOW() 每次执行都不同，索引构建和后续查询无法对齐语义。
常见错误现象：Error: functions in a partial index expression must be marked IMMUTABLE
- 只允许
IMMUTABLE函数：如upper()、substr()、比较常量（status = 'active'）、布尔字段判断（is_deleted = false） - 禁止
VOLATILE或STABLE函数：如CURRENT_DATE、random()、session_user - 若真要按“最近7天”建索引，得用固定时间点（如
created_at >= '2024-06-01'），并定期重建索引或换成分区表
WHERE 条件越精确，索引体积越小，但查询覆盖范围也越窄
partial index 的存储节省不是线性的，它取决于被过滤掉的数据比例和数据分布。一个 WHERE status IN ('pending', 'processing') 可能只排除 5% 行，索引几乎没省空间；而 WHERE is_archived = false AND deleted_at IS NULL 若筛掉 95% 行，索引大小可能只有全量索引的 1/10。
实操建议：
- 用
pg_total_relation_size('index_name')对比 partial 和普通索引的实际字节数 - 注意 B-tree 索引本身有最小开销（每个索引页约 8KB），如果只索引几百行，物理大小未必明显下降
- WHERE 条件中字段最好已存在于查询的
WHERE或JOIN条件中，否则优化器可能干脆不用该索引
WHERE 条件字段必须出现在查询谓词中，索引才可能生效
partial index 不会自动“兜底”。即使你建了 WHERE is_deleted = false，但查询写的是 select * FROM orders WHERE id = 123，PostgreSQL 通常不会用它——因为优化器无法确认该索引是否覆盖所有可能的 id 值（哪怕逻辑上 is_deleted 是主键的一部分）。
关键点：
- 查询的
WHERE必须显式包含 partial index 的WHERE条件，或其逻辑等价形式（如is_deleted IS NOT TRUE与is_deleted = false一般可识别，但NOT is_deleted在某些版本不触发） - 可以用
EXPLAIN看执行计划里是否出现你的 partial index 名字；若没出现，加个冗余条件试试：AND is_deleted = false - 复合 partial index（如
WHERE tenant_id = 123 AND status = 'active'）要求查询同时满足两个条件，少一个都不走
部分索引在 UPDATE/DELETE 时仍需维护，且可能拖慢写入
很多人以为 partial index “只索引一部分”，所以写入开销也小。错。只要某行满足 partial index 的 WHERE 条件，INSERT/UPDATE/DELETE 它时，索引就必须同步更新——和普通索引一样走完整 B-tree 插入/删除流程。
容易被忽略的地方：
- UPDATE 一行时，如果它的字段变化导致它“进入”或“离开”partial index 范围（比如把
status从'draft'改成'published'），PostgreSQL 会先删旧索引项、再插新索引项 - 高并发写入场景下，partial index 的锁粒度和普通索引一致，热点数据集中在某个子集时，反而更容易出现索引页争用
- 别为了省空间盲目建多个 partial index——每个都增加 WAL 日志量、缓冲区压力和 vacuum 负担
真正影响存储和性能平衡的，从来不是“建不建”，而是“建哪几个、条件怎么写、查的时候怎么配”。稍不注意，省下的磁盘空间全被多出来的 WAL 和缓存抖动吃掉了。