必须用 instead of delete 触发器替代 after delete，因其可拦截删除、先清子表再删主表，避免外键不一致；需手动执行主表删除、完整匹配复合主键、禁用多表delete语法、避免与on delete cascade冲突，并严格控制清理边界和权限。
必须用 INSTEAD OF DELETE，不能用 AFTER
SQL Server 的 AFTER DELETE 触发器在主表行物理删除后才执行，此时你拿不到完整的 DELETED 表上下文来安全删子表——尤其当子表有外键约束时，AFTER 里删子表会撞上“父记录已删但子表引用还在”的状态不一致问题。而 INSTEAD OF DELETE 会拦截原始 DELETE 语句，先手动清理子表，再显式删主表，全程可控。
常见错误现象是：触发器编译通过、执行无报错，但子表数据没删，主表也没删——本质是忘了在触发器末尾补上 DELETE FROM 主表 WHERE id IN (SELECT id FROM DELETED)。
-
DELETED是只读临时表，结构与主表一致，仅在触发器内有效 - 若主表有多个字段构成复合主键，
WHERE条件必须完整匹配所有键字段 - 不能在
INSTEAD OF触发器里调用另一个会修改同一主表的存储过程，否则可能触发嵌套限制（默认关闭）
DELETE 多表语法在触发器里要拆成单表语句
SQL Server 支持 DELETE t1, t2 FROM t1 JOIN t2 这种写法，但它在触发器体中不可靠：一是部分版本解析异常，二是事务锁粒度难控，三是无法精准绑定 DELETED 中的待删主键集。实际应拆为明确的单表 DELETE + 子查询。
例如主表 Student(SNO) 关联 SC(SNO)，正确写法是：
DELETE FROM SC WHERE SNO IN (SELECT SNO FROM DELETED);
而不是：
DELETE SC FROM SC JOIN DELETED ON SC.SNO = DELETED.SNO;
- 用
IN (SELECT ...)能利用索引，JOIN DELETED在触发器内可能被优化为全表扫描 - 如果子表数据量大（如百万级
SC记录），直接DELETE可能锁表太久；可加TOP (1000)分批删，或改用异步通知 - 别在触发器里对同一子表反复执行
DELETE（比如循环处理DELETED每行），集合操作一次到位
外键约束和触发器必须互斥
如果子表已经定义了 ON DELETE CASCADE，再建触发器清理同一张子表，会导致行为冲突：数据库可能跳过触发器（走外键逻辑），也可能触发器删完后外键再删一次，报 Cannot insert duplicate key 或静默失败。
务必先检查现有约束：
SELECT name, delete_referential_action_desc FROM sys.foreign_keys WHERE parent_object_id = OBJECT_ID('SC');
- 若结果含
CASCADE，就别写触发器——外键级联更轻量、原子性更强 - 若子表外键是
NO ACTION或SET NULL，才需要触发器兜底 - 跨 schema 的子表（如
dbo.SCvslog.SC）需确认触发器用户有对应 DELETE 权限，否则删操作静默跳过
多层关联必须控制清理边界
比如 Student → SC → Score，不要在 Student 的触发器里连带删 Score。原因有三：一是锁范围扩大（从 Student 表扩散到 Score 表），二是违反单一职责（SC 才该负责清理 Score），三是容易引发嵌套触发器循环（尤其 Score 表也有自己的 INSTEAD OF 触发器时）。
合理分工是：
-
Student触发器只删SC -
SC表自己定义INSTEAD OF DELETE，负责删Score - 两层触发器都用
INSTEAD OF，且各自只处理直系子表
真正容易被忽略的是事务隔离级别影响：在 READ COMMITTED 下，DELETED 表反映的是语句开始时的状态，若并发删除同一学生多条记录，可能漏删刚插入但未提交的 SC 行。这种边界情况得靠应用层加锁或业务校验兜底。
