外键级联操作（如on delete cascade）不触发insert/update/delete触发器，因其由innodb直接处理，不经过sql层；审计级联变更需改用应用层控制、存储过程或子表独立触发器。
外键约束会绕过触发器执行
MySQL 中，INSERT、UPDATE、DELETE 触发器不会在由外键级联操作（如 ON DELETE CASCADE）引发的隐式数据变更中被触发。这是关键前提——不是“不能联合”，而是“外键动作不走触发器路径”。
常见误解是以为加了 BEFORE UPDATE 就能拦截所有更新，结果发现级联更新后日志没写、审计字段没变、自定义逻辑完全没执行。
- 外键的
CASCADE、SET NULL、RESTRICT等行为由存储引擎（InnoDB）直接处理，不经过 SQL 层的触发器机制 - 只有显式执行的 DML 语句（如手动
DELETE FROM parent）才会激活对应触发器 -
NO ACTION和RESTRICT表现一致：阻止非法操作，但也不触发触发器
想审计/记录级联变更？得用替代方案
如果业务要求对级联删除或更新做日志、通知或额外校验，必须放弃依赖触发器捕获这些动作，改用以下方式之一：
- 把级联逻辑从外键移到应用层：先查子记录，再手动
DELETE子表，最后删父表 —— 这样每一步都能进触发器 - 用存储过程封装完整删除流程，内部显式调用
DELETE并插入审计日志 - 对子表建
AFTER DELETE触发器，但它只响应“你亲手删子行”的操作，不响应“因父行删除而自动删子行” - 启用 MySQL 的通用查询日志（
general_log）或使用PERFORMANCE_SCHEMA监控语句，但粒度粗、开销大，不适合业务逻辑嵌入
触发器与外键共存时的冲突风险
当触发器和外键同时存在且逻辑有交集时，容易出现违反约束或死锁。典型场景：
CREATE TABLE orders ( id INT PRIMARY KEY, customer_id INT, FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE ); DELIMITER $$ CREATE TRIGGER tr_orders_before_delete BEFORE DELETE ON orders FOR EACH ROW BEGIN INSERT INTO order_audit VALUES (OLD.id, 'deleted'); END$$ DELIMITER ;
这段代码看似无害，但若执行 DELETE FROM customers WHERE id = 123，InnoDB 会先级联删 orders 行，而这个过程不进触发器 —— 所以 order_audit 不会记录。更危险的是，如果触发器里试图修改被外键引用的列（比如 SET OLD.customer_id = NULL），会直接报错 ERROR 1362 (HY000): Updating of OLD row is not allowed in after trigger 或违反外键约束。
-
BEFORE触发器中修改OLD字段仅限于NEW可赋值的列，且不能破坏外键引用完整性 - 触发器内执行的 DML 若涉及外键关联表，可能触发二级外键动作，形成不可预测的链式反应
- InnoDB 对触发器+外键混合事务的加锁顺序较复杂，高并发下易出现死锁，错误信息类似
ERROR 1213 (40001): Deadlock found when trying to get lock
真正安全的联合使用方式
唯一稳妥的做法，是让触发器和外键各司其职、互不干扰：
- 外键只负责强制引用完整性（
RESTRICT或NO ACTION），禁用CASCADE和SET NULL - 所有业务级联逻辑（包括日志、状态同步、缓存失效）全部收口到触发器或应用层
- 例如：父表
BEFORE DELETE触发器中主动DELETE FROM child WHERE parent_id = OLD.id，再删父行 —— 这样子表的AFTER DELETE触发器也能正常运行 - 务必在触发器开头加
IF NOT EXISTS (SELECT 1 FROM information_schema.TABLES ...)类检查，避免因表不存在导致整个事务失败
外键和触发器不是非此即彼的选择，但它们的执行时机、权限边界和错误传播路径完全不同。硬凑在一起，往往调试半天才发现问题出在“以为它该触发，其实根本没走那条路”。
