无法在触发器中直接判断DELETE是否来自级联，因DELETED/OLD表不携带删除来源信息；ON DELETE CASCADE由存储引擎直接执行，不经过SQL解析层，故触发器无法感知调用链路。
触发器里无法直接判断DELETE是否来自级联
SQL标准和主流数据库（MySQL、SQL Server、PostgreSQL）的触发器机制中，DELETED（SQL Server）或 OLD（MySQL）逻辑表只提供被删行的数据快照，不携带“删除来源”元信息。也就是说，无论是外键 ON DELETE CASCADE 触发的子表删除，还是用户显式执行的 DELETE FROM child_table WHERE ...，触发器看到的都是同一类事件——它只知道自己被 DELETE 操作激活了。
为什么级联删除不会“通知”触发器？
这是设计使然，不是缺陷：
-
ON DELETE CASCADE是由存储引擎/约束系统在事务内部直接执行的物理操作，不经过用户 SQL 解析层，因此不会“发出”一个可被触发器感知的“带上下文的 DELETE 语句” - MySQL 明确文档指出：“触发器不会被级联的外键动作激活”；SQL Server 虽然会为级联删除触发子表上的
AFTER DELETE，但该触发器仍无法区分调用链路 - 哪怕你在父表上建了
INSTEAD OF DELETE，它也只拦截父表语句本身，子表的级联动作仍是后台自动行为，不可见、不可控
可行的替代方案：用业务标记 + 条件绕过
如果必须差异化处理（比如级联时跳过日志记录，手动删时要审计），只能靠外部协作：
- 禁用外键级联，改用显式逻辑：在父表触发器中手动
DELETE FROM child_table WHERE parent_id = ...，此时你完全控制流程，可加标志变量或临时表标记“本次是级联流” - 约定删除入口：所有业务删除走统一存储过程（如
sp_delete_order @order_id, @is_cascade = 0），由该过程决定是否删子表，并传参控制子表触发器行为 - 用会话级上下文：SQL Server 可用
CONTEXT_INFO()在父操作前设置标记，子表触发器读取；MySQL 8.0+ 可用SET @my_flag = 'cascade'配合SELECT @my_flag判断（注意会话隔离性）
最容易被忽略的陷阱
很多人试图在触发器里查 sys.dm_exec_requests 或 information_schema 推断调用栈，这在绝大多数场景下都不可靠：
- 触发器运行在事务上下文中，原始语句可能已结束，会话信息不可追溯
- 并发环境下，多个 DELETE 同时发生，
@my_flag类变量极易被覆盖 - 即使能拿到调用 SQL 文本，也无法区分“
DELETE FROM orders”和“DELETE FROM orders WHERE id=123”是否源于级联——因为级联本身不生成可捕获的语句
真正安全的做法，是放弃“自动识别”，转而通过架构设计把“是否级联”这个意图显式暴露出来。
