外键约束 deferrable 允许将参照完整性检查推迟到事务结束时，解决批量导入中因循环依赖或插入顺序导致的外键冲突；需建表时声明，postgresql 支持，mysql 不支持。
外键约束 deferrable 是什么，为什么批量导入时需要它
默认的外键约束是立即检查（immediate）：每条 INSERT 或 UPDATE 执行完就立刻验证参照完整性。批量导入时，如果表之间有循环依赖（比如 orders 引用 customers，而 customers 又通过 preferred_order_id 引用 orders），或者数据插入顺序和外键指向顺序不一致，就会直接报错：insert or update on table "orders" violates foreign key constraint "orders_customer_id_fkey"。
DEFERRABLE 的作用，就是把约束检查从“每条语句后”推迟到“事务结束前”。只要整个事务最终满足约束，中间暂时不一致也没关系。
关键点：
-
DEFERRABLE是声明约束时的属性，必须建表或加约束时指定，运行时不能改 - 只对当前事务生效，不影响其他连接或其他事务
- PostgreSQL 支持，MySQL 不支持（5.7/8.0 均无
DEFERRABLE），SQLite 部分支持但行为受限
initially deferred 和 initially immediate 有什么区别
两者都要求约束先声明为 DEFERRABLE，区别在于事务开始时的默认检查时机：
-
INITIALLY IMMEDIATE：默认立即检查，但你可以手动执行SET CONSTRAINTS ALL DEFERRED切换为延迟检查 -
INITIALLY DEFERRED：默认整个事务都延迟检查，直到COMMIT时才统一校验
批量导入场景下，INITIALLY DEFERRED 更省心——不用在 SQL 脚本开头加额外命令，也不用担心漏掉 SET CONSTRAINTS。但要注意：一旦设成 INITIALLY DEFERRED，单条语句的即时报错能力就没了，调试时可能更难定位哪一行数据有问题。
示例建表语句：
CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INTEGER REFERENCES customers(id) DEFERRABLE INITIALLY DEFERRED );
批量导入时怎么配合使用（含 pg_restore / COPY / 脚本）
PostgreSQL 的 COPY、pg_restore 或自定义导入脚本，只要包裹在事务里，就能利用 DEFERRABLE 约束的延迟特性：
-
pg_restore -d db_name --disable-triggers不是替代方案，它绕过约束，风险高；正确做法是用--use-set-session-authorization+ 确保目标约束已设为DEFERRABLE - 手写导入脚本时，务必用
BEGIN; ... INSERTs ... COMMIT;包裹，否则每个INSERT单独提交，延迟无效 -
COPY本身不开启事务，需显式写成：BEGIN; COPY orders FROM '/tmp/orders.csv'; COPY customers FROM '/tmp/customers.csv'; COMMIT; - 如果表已有非
DEFERRABLE约束，得先ALTER TABLE ... DROP CONSTRAINT，再ADD CONSTRAINT ... DEFERRABLE INITIALLY DEFERRED，不能直接修改现有约束
容易被忽略的坑：约束名、事务边界与错误定位
延迟约束不是“免检金牌”，COMMIT 时仍会失败，而且错误信息往往只说“违反外键约束”，不告诉你具体哪一行出问题：
- 错误里提到的约束名（如
"orders_customer_id_fkey"）必须和你ALTER TABLE时用的名字完全一致，大小写敏感 - 如果事务里混用了
INITIALLY IMMEDIATE和INITIALLY DEFERRED约束，得用SET CONSTRAINTS constraint_name DEFERRED逐个控制，ALL DEFERRED会一并处理，容易误伤 - 日志中看到
ERROR: insert or update on table "x" violates foreign key constraint时，说明事务已回滚，但没留中间状态——建议导入前先用SELECT检查引用字段是否存在，或临时关掉约束做预验证 - 并发导入时，另一个事务可能在你
COMMIT前删掉了你正要引用的记录，导致延迟检查失败——这不是配置问题，是业务逻辑需要重试或加锁
真正麻烦的从来不是加 DEFERRABLE 这几个字，而是约束存在循环依赖、且业务上又无法拆解时，你得在数据模型层面重新权衡，而不是靠延迟检查硬扛。
