TRUNCATE前必须确认表无外键依赖，否则报错；它比DELETE更严格，不触发触发器且要求无外键引用，需先查依赖、删/禁用外键或改用DELETE+重置ID。
TRUNCATE 之前必须确认表无外键依赖
直接执行 truncate table 报错 cannot truncate a table referenced in a foreign key constraint 是最常见卡点。它比 delete 更严格：不走逐行检查，也不触发触发器，但要求表不能被其他表的外键引用。
- 先查依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table'; - 要么删/禁用外键（
ALTER TABLE ref_table DROP FOREIGN KEY fk_name），要么改用DELETE FROM+RESET IDENTITY（PostgreSQL）或DBCC CHECKIDENT（SQL Server） - MySQL 8.0+ 支持临时禁用外键检查：
SET FOREIGN_KEY_CHECKS = 0;，但务必配对恢复，且仅限当前会话
TRUNCATE 和 DELETE 在覆盖导入中的行为差异
覆盖导入时选错命令，轻则慢几秒，重则锁表失败或主键冲突。
-
TRUNCATE重置自增计数器、释放存储空间、不可回滚（多数数据库）、不走事务日志（极快），适合全量替换场景 -
DELETE FROM保留自增起点、逐行记录日志（可回滚）、触发触发器、可能被长事务阻塞，适合需审计或部分清理的导入 - PostgreSQL 中
TRUNCATE默认不级联，加CASCADE才清空依赖视图/序列，但会连带清掉关联数据——不是所有“覆盖”都想要这个效果
导入脚本里怎么安全组合 TRUNCATE + INSERT
把 TRUNCATE 和后续 INSERT 写在同一个事务里，是防止中间状态残留的关键。
- MySQL：用
BEGIN; TRUNCATE TABLE t; LOAD DATA INFILE ...; COMMIT;包裹，避免TRUNCATE后导入中断导致空表 - PostgreSQL：显式事务 +
TRUNCATE ... RESTART IDENTITY（否则新插入可能主键重复） - 别在脚本开头写
TRUNCATE然后分批INSERT—— 中间出错就只剩半截数据，且无法靠事务回滚补救 - 如果导入工具（如
psql -c或mysqlimport）不支持事务，优先考虑用CREATE TABLE AS+RENAME替代
分区表或大表下 TRUNCATE 的实际影响
百万级以上数据时，TRUNCATE 表面快，但背后有隐藏成本。
- 某些数据库（如旧版 MySQL InnoDB）对大表
TRUNCATE会重建表结构，耗时且阻塞 DML，不是瞬间完成 - 分区表建议按分区
TRUNCATE PARTITION p1，而不是整表——既快又不影响其他分区查询 - 云数据库（如 AWS RDS）上，
TRUNCATE可能触发自动备份快照或日志归档，观察监控里的 I/O spike 和连接等待时间 - 如果表上有全文索引、空间索引等特殊结构，
TRUNCATE后需手动重建，否则后续INSERT可能报错
