postgresql已有表加on delete cascade需先drop再add约束，因不支持直接修改外键行为；须查约束名、显式指定schema、注意access exclusive锁及递归删除风险。
PostgreSQL已有表怎么加ON DELETE CASCADE
不能直接用 ALTER TABLE ... ADD FOREIGN KEY ... ON DELETE CASCADE 补上——PostgreSQL 不支持在已有外键上“修改行为”，必须先删旧约束、再建新约束。这和 MySQL 类似，但 PostgreSQL 允许你用名字精准操作，不依赖匿名约束名推断。
- 先查出当前外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'child_table' AND COLUMN_NAME = 'foreign_key_col' AND CONSTRAINT_SCHEMA = 'public'; - 确认约束类型是 FOREIGN KEY（排除 CHECK 或 UNIQUE）：
SELECT constraint_type FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE CONSTRAINT_NAME = 'fk_name'; - 执行两步操作：先
DROP CONSTRAINT，再ADD CONSTRAINT带ON DELETE CASCADE；注意要显式写出完整引用路径，比如REFERENCES parent_schema.parent_table(id)（跨 schema 必须写全）
为什么DROP + ADD会锁表，以及怎么减小影响
PostgreSQL 在 ALTER TABLE ... DROP CONSTRAINT 和 ADD CONSTRAINT 期间会对表加 ACCESS EXCLUSIVE 锁，阻塞所有读写。这不是语法问题，而是约束重建需校验全表数据一致性。
- 如果子表很大（比如千万级），
ADD CONSTRAINT可能卡住几秒到几分钟，期间应用写入失败 - 避免高峰操作：低流量时段执行；若不可控，可考虑先加
NOT VALID约束（跳过全表扫描），后续再VALIDATE CONSTRAINT分批校验 -
NOT VALID写法示例：ALTER TABLE child_table ADD CONSTRAINT fk_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE NOT VALID;—— 此时级联已生效，但不校验历史数据
ON DELETE CASCADE 在 PostgreSQL 中的真实递归行为
它不是只删一层子记录，而是顺着外键链自动往下走——只要下一级也有带 ON DELETE CASCADE 的外键，就会继续删。比如 users → orders → order_items → inventory_logs，删一个用户，可能触发四层删除。
- 执行前必须逐层
SELECT COUNT(*)摸清规模，不能只看第一层子表数量 - 特别注意循环依赖风险：A→B→C→A 这种结构即使语法通过，运行时也会报错
recursive deletion not allowed -
RETURNING无法返回被级联删掉的子表行，它只返回主DELETE语句直接影响的那批父表记录
和 MySQL 的关键差异点：跨 schema 和默认行为
PostgreSQL 支持跨 schema 外键（如 schema_a.child_table → schema_b.parent_table），但 MySQL 8.0+ 仍限制外键必须同 schema。这意味着你在 PostgreSQL 里加 ON DELETE CASCADE 时，REFERENCES 后必须显式带上 schema 名，漏写会报 relation does not exist。
- MySQL 默认外键行为是
RESTRICT，PostgreSQL 也是，这点一致 - 但 PostgreSQL 的
ON DELETE CASCADE在事务中完全原子：要么整条链删干净，要么全部回滚；MySQL InnoDB 同样如此，但 MyISAM 根本不支持外键 - 别信 ORM 迁移脚本生成的 SQL —— Django 的
on_delete=models.CASCADE或 EF Core 的OnDelete(DeleteBehavior.Cascade)只影响迁移文件，最终是否生效取决于你有没有真把约束刷进数据库
NOT VALID 约束不会触发级联——它会，只是不校验存量数据。
