TRUNCATE CASCADE 要求外键必须显式声明 ON DELETE CASCADE，否则报错；验证需查 pg_constraint 中 confdeltype 字段是否为 'c'，非则不可用；应急可临时设 session_replication_role = 'replica' 并显式列出表名清空，但高危且须严格管控。
TRUNCATE CASCADE 要求外键必须显式声明 ON DELETE CASCADE
很多人执行 TRUNCATE TABLE parent CASCADE 时直接报错：ERROR: cannot truncate a table referenced in a foreign key constraint。这不是语法写错了，而是外键约束本身没配对——PostgreSQL 的 TRUNCATE CASCADE 不看“有没有外键”，只认“有没有 ON DELETE CASCADE”。哪怕表之间已有外键，只要建表时没写这五个字，CASCADE 就拒绝工作。
验证方法很简单：
SELECT conname, confupdtype, confdeltype, confmatchtype FROM pg_constraint WHERE confrelid = 'sys_dict'::regclass AND contype = 'f';
重点看 confdeltype 字段：值为 c 才表示 ON DELETE CASCADE 已启用；如果是 a（restrict）或 n（no action），就无法用 TRUNCATE CASCADE。
不能 TRUNCATE 的常见真实场景和绕过方式
线上表已上线多年，外键是 ON DELETE RESTRICT 或根本没写动作，又不能改表结构？这时候硬加 CASCADE 会触发锁升级失败，或影响业务稳定性。应急可用以下方式：
-
SET session_replication_role = 'replica';—— 临时跳过所有外键检查和触发器 - 执行
TRUNCATE TABLE parent, child1, child2;—— 显式列出所有要清空的表 -
SET session_replication_role = 'origin';—— 立即恢复检查，否则后续 INSERT 可能写入脏数据
⚠️ 注意：session_replication_role = 'replica' 是高危操作。它不校验外键、不触发 ON INSERT、也不发通知，且并发写入可能破坏一致性。仅限维护窗口内、确认无其他连接写入时使用。
TRUNCATE vs DELETE：别用错时机
TRUNCATE 快，但代价明确；DELETE FROM 慢，但可控。选哪个取决于你的真实需求：
- 要重置自增序列？用
TRUNCATE TABLE name RESTART IDENTITY - 要删部分数据？
TRUNCATE不支持WHERE，只能用DELETE - 表上有
BEFORE DELETE触发器且必须执行？TRUNCATE完全跳过它 - 担心长事务阻塞？
TRUNCATE需要ACCESS EXCLUSIVE锁，如果子表正被SELECT FOR UPDATE占着，整个命令会卡住甚至超时
另外，TRUNCATE 在事务中可回滚，但一旦 COMMIT，就彻底不可逆——它不进 WAL 日志队列，也没有行级备份点。
分区表、继承表和 ONLY 关键字容易踩坑
如果你的 sys_dict 实际是分区表或继承体系的一部分，直接 TRUNCATE sys_dict CASCADE 可能误删子分区或子表。PostgreSQL 默认会递归清空所有子表（包括继承链和分区），除非你加 ONLY：
TRUNCATE ONLY sys_dict CASCADE —— 只清空主表，不碰任何子表/分区
查当前表是否为分区父表：
SELECT inhrelid::regclass AS child_table FROM pg_inherits WHERE inhparent = 'sys_dict'::regclass;
如果返回结果非空，说明它有子表，务必先确认是否真要一并清空。PostgreSQL 12+ 对分区表的 CASCADE 支持仍有限，建议先手动查 pg_inherits，再决定是否加 ONLY 或分步操作。
