TRUNCATE TABLE 因外键约束被禁止，须先禁用（推荐 NOCHECK）或删除外键；清空顺序为子表→父表，再显式 CHECK CONSTRAINT 恢复；权限受限时可用 DELETE + 事务 + DBCC CHECKIDENT 替代。
TRUNCATE TABLE 会直接报错：外键约束阻止操作
你执行 TRUNCATE TABLE orders 时，SQL Server 立刻抛出错误：The TRUNCATE TABLE statement is not allowed on tables referenced by a FOREIGN KEY constraint。这不是权限或语法问题，是引擎层硬性限制——TRUNCATE 不触发触发器、不记录逐行日志，无法保证外键引用的子表数据一致性，所以直接禁止。
必须先禁用或删除外键，再 TRUNCATE
想保留 TRUNCATE 的性能优势（日志少、速度快、重置标识列），就得临时解除外键约束。两种主流做法：
- 用
ALTER TABLE ... NOCHECK CONSTRAINT暂时禁用外键检查（推荐）：它不删约束定义，只跳过验证，后续可快速恢复； - 用
ALTER TABLE ... DROP CONSTRAINT彻底删掉外键（慎用）：后续需手动重建，容易遗漏或写错定义。
注意：禁用外键后，TRUNCATE 可以执行，但你要确保子表（如 order_items）也同步清空，否则后续启用约束时会因数据不一致而失败。
安全顺序：子表 → 父表，且需显式启用约束
外键依赖有方向性。比如 order_items.order_id → orders.id，那么必须：
- 先
TRUNCATE TABLE order_items（子表）； - 再
TRUNCATE TABLE orders（父表）； - 最后用
ALTER TABLE ... CHECK CONSTRAINT重新启用所有外键（不是自动恢复）。
如果顺序反了，哪怕外键已禁用，也可能因事务隔离或缓存状态导致隐性冲突；而启用约束这步常被忽略，结果表看似清空了，实际外键处于 NOT TRUSTED 状态，影响查询优化器判断。
替代方案：DELETE + 事务 + 重置标识列
若你无法控制外键（比如生产库无 ALTER 权限），或担心禁用约束的风险，就只能用 DELETE：
-
DELETE FROM orders（无 WHERE）能绕过外键限制，但必须确保子表已清空，否则仍报错； - 加
BEGIN TRAN包裹父子表DELETE，保证原子性； - 执行完后用
DBCC CHECKIDENT ('orders', RESEED, 0)重置自增种子，模拟TRUNCATE效果。
这个组合没 TRUNCATE 快，日志量大，但行为完全可控，适合权限受限或高敏感环境。
外键不是障碍，而是提醒你：数据关系不能靠“强行清空”来抹平。真正容易被忽略的，是禁用约束后忘记 CHECK CONSTRAINT，以及子表清空与父表清空之间缺少事务包裹——这两点会让表看起来“干净”，实则埋下后续插入失败或查询计划劣化的隐患。
