首先给你一个明确的好消息：**如果你用的是PostgreSQL 9.5或更新版本，直接在EXCLUDE约束后加WHERE user_id IS NULL是完全可行的！**这是最原生、优雅且高效的方案，不需要绕弯路。

直接可行的原生语法 #

你只需要把WHERE子句放在约束的末尾即可，完整代码如下：

ALTER TABLE my_table ADD CONSTRAINT no_overlap
EXCLUDE USING gist (product_id WITH =, applicable_period WITH &&)
WHERE (user_id IS NULL);

这个约束只会对user_id IS NULL的行生效，完美匹配你的需求。

如果你在用低于9.5的老版本（现在很少见，但还是给你备选） #

如果你的PostgreSQL版本太旧不支持带WHERE的EXCLUDE约束，可以用「部分GIST索引转约束」的方式模拟：

1. 先创建一个带过滤条件的GIST索引，包含你的排除规则：

CREATE INDEX no_overlap_partial_idx
ON my_table USING gist (product_id WITH =, applicable_period WITH &&)
WHERE user_id IS NULL;

2. 再把这个索引升级为约束，强制数据库执行检查：

ALTER TABLE my_table ADD CONSTRAINT no_overlap_partial
USING INDEX no_overlap_partial_idx;

这个方案的性能和原生带WHERE的约束几乎没有区别，只是多了一步操作。

表分区是否适合？ #

表分区是个可选方案，但只推荐给数据量很大的场景：

• 你可以按user_id IS NULL作为分区键，把表拆成两个分区：
  • 一个分区专门存user_id IS NULL的数据，在这个分区上创建普通的EXCLUDE约束（不需要WHERE）
  • 另一个分区存user_id IS NOT NULL的数据，不需要加这个约束
• 优势：约束检查只会针对目标分区，减少了索引扫描的范围，查询和写入性能都会更好；同时分区还能优化备份、清理等操作
• 劣势：需要额外的分区维护工作，小表用分区反而会增加复杂度，完全没必要

为什么不优先推荐触发器？ #

你提到可以用触发器，但我不建议把它作为首选：

• 触发器是行级逻辑，每次插入/更新都要执行自定义代码，性能远不如基于GIST索引的原生约束
• 触发器需要编写PL/pgSQL代码，维护成本更高，很容易漏掉边缘场景（比如UPDATE或DELETE操作的处理）
• 原生约束是数据库层面强制的，可靠性更高，不会因为触发器被禁用或代码bug而失效

内容的提问来源于stack exchange，提问作者Andrey Deineko