数据工程面试：PostgreSQL 18 的 NOT ENFORCED 约束能解决什么问题？

题干与适用场景

一张历史订单表 orders 中有少量找不到客户的 customer_id。团队想在 PostgreSQL 18 中先把外键写进 schema，明确目标关系，同时不让旧数据修复被一次迁移阻塞。请判断 NOT ENFORCED 是否合适，说明它和普通外键的差异、如何发现违规行、如何分阶段切换，以及为什么不能把它当成数据已经合规的证明。

面试官考察点

• 能否区分“声明业务意图”和“由数据库拒绝非法写入”。
• 能否说明 NOT ENFORCED 不会在写入时检查约束，因而不能提供运行时完整性保证。
• 能否设计历史数据扫描、增量监控、修复批次和最终切换门槛。
• 能否识别 dump、恢复、跨服务写入、回滚与应用兼容风险。
• 能否解释为什么不能借用未确认的约束改变查询或优化假设。

回答前需要澄清的问题

• 约束是外键还是 CHECK？违规数据的规模、增长速度和修复负责人是谁？
• 写入路径是否只有 PostgreSQL，还是还有 ETL、批处理或绕过应用的脚本？
• 旧客户端能否处理新增约束名、迁移锁和切换失败？
• 最终切换必须零违规，还是允许按租户分批完成？
• 需要保留哪些证据，才能证明每次扫描覆盖了完整数据范围？

30 秒回答框架

“NOT ENFORCED 适合先把 CHECK 或外键的意图写入 schema，同时允许历史脏数据继续存在；它不会替数据库检查新写入，所以不是完整性保证。我会先建立全量违规基线，再对新写入做增量检查和告警，修复或隔离历史行，最后在零违规和回滚演练通过后切换到 enforced。整个期间不能让客户端或优化器把它当成已验证的事实。”

分步骤深入解答

先明确语义和风险

PostgreSQL 18 允许 CHECK 与 foreign key 指定 NOT ENFORCED。数据库保存约束声明，但不会按普通 enforced 约束检查写入。约束元数据可用于文档、治理和迁移协调；它不替代应用、ETL 或独立数据质量检查。

建立全量与增量证据

对外键做反连接扫描，找出没有父表记录的子表行；对 CHECK 运行同一谓词的反向查询。记录扫描时间、快照或水位、分区范围和结果哈希。之后在 CDC、写入作业或质量任务中检查新增与更新行，避免只做一次历史扫描。

SELECT o.order_id, o.customer_id
FROM orders AS o
LEFT JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id IS NOT NULL
  AND c.customer_id IS NULL;

设计修复和切换门槛

把孤儿订单分为可自动补齐、需要业务确认和必须隔离三类。为修复作业设置幂等键、批次上限和停止条件。切换前要求全量扫描为零、增量窗口无新增违规、备份恢复演练通过、所有写入路径纳入监控。随后在低峰执行 enforced 迁移，观察锁等待和错误率。

处理恢复与跨环境差异

迁移失败时保留 NOT ENFORCED 声明和已修复记录，回滚应用发布与质量任务，不要假装约束已 enforced。测试 dump/restore、只读副本、灾备集群和旧版本客户端；确保目标环境理解 conenforced 元数据，不能只依赖 ORM 是否显示该字段。

高质量示范回答

“我会把 NOT ENFORCED 当成迁移期契约，不当成数据库护栏。先对订单和客户做完整反连接，记录分区范围和水位，再让 CDC 任务检查新写入。孤儿行按自动修复、人工确认和隔离分类，所有修复可幂等重跑。只有全量与增量都零违规、备份恢复通过、写入路径完整纳管，才在低峰把外键切到 enforced，并监控锁等待。任何阶段都不会让客户端或查询优化假设这条约束已经被验证。”

常见错误

• 错误表现： 看到 schema 有外键就认为数据已一致 → 失败原因： NOT ENFORCED 不检查写入 → 修正方法： 用全量和增量质量证据证明状态。
• 错误表现： 只扫描一次历史表 → 失败原因： 新的绕过路径仍会产生违规 → 修正方法： 覆盖 CDC、ETL、脚本和应用写入。
• 错误表现： 直接把约束改成 enforced → 失败原因： 迁移可能因历史脏数据或锁失败 → 修正方法： 先修复、演练、设置门槛，再在低峰切换。
• 错误表现： 把未 enforced 约束当成优化提示 → 失败原因： 声明没有提供完整性证明 → 修正方法： 只依据已验证统计和数据库实际支持的优化规则。

追问及应对

CHECK 约束能否引用另一张表来完成跨表校验？

不要依赖这种做法。行级 CHECK 不保证其他行变化后的全局状态，dump/restore 顺序也可能暴露问题；跨表关系应优先使用外键或独立质量任务。

如果违规数量永远降不到零怎么办？

保留 NOT ENFORCED，把违规行纳入隔离或业务例外清单，并设置明确的增长上限、责任人和到期日。若约束只是文档而非近期可执行的契约，应重新评估是否需要写入 schema。

能否靠应用层校验来替代 enforced 外键？

只能作为过渡或补充。多写入者、并发和绕过应用的脚本会让应用校验失效；最终完整性边界仍应由数据库约束或可验证的数据管道承担。

如何验证灾备库没有悄悄偏离？

在主库和恢复副本上运行同一质量查询，比较扫描水位、违规数量和结果摘要，并把恢复演练纳入切换门槛。

参考资料

• PostgreSQL Documentation 18：Constraints
• PostgreSQL Documentation 18：CREATE TABLE
• PostgreSQL Documentation 18：Release Notes
• Greg Low：SQL Interview: 64 Disabling and reenabling constraints
• MockIF：SQL Interview Questions 2026

面试作答要点

先说清 NOT ENFORCED 只声明约束、不提供写入检查，再给出全量基线、增量监控、修复分类、切换门槛和恢复证据。

一句话总结

NOT ENFORCED 是迁移期的可见契约，数据工程师仍必须用独立证据证明数据合规，才能承担 enforced 的运行时护栏。