MySQL触发器是数据库中与表关联的特殊的存储过程，会在表的INSERT、UPDATE、DELETE等事件发生时自动执行。在复杂的业务场景下，开发者可能会遇到一个触发器的执行操作触发另一个触发器的场景，也就是触发器嵌套的情况。
MySQL触发器嵌套的基本规则
MySQL默认是支持触发器嵌套的，也就是当一个触发器执行的操作符合另一个触发器的触发条件时，另一个触发器会被自动触发执行。不过嵌套的触发需要满足几个基础条件：
- 嵌套的触发器必须属于不同的表，或者同一表的不同触发事件，不能出现同一个触发事件无限递归触发的情况
- MySQL有一个系统变量
max_sp_recursion_depth控制存储过程和触发器的递归深度，默认值为0，也就是默认不允许递归嵌套，需要手动调整该值才会允许递归场景 - 嵌套触发器的执行顺序遵循触发事件的时间顺序，比如BEFORE触发器会先于AFTER触发器执行
触发器嵌套的示例演示
下面通过两个表的场景演示非递归的触发器嵌套效果，首先创建两个测试表：
-- 创建用户表
CREATE TABLE user_info (
id INT PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(50) NOT NULL,
balance DECIMAL(10,2) DEFAULT 0
);
-- 创建用户操作日志表
CREATE TABLE user_log (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
log_content VARCHAR(200),
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
接下来给user_info表的UPDATE事件创建AFTER触发器，当更新用户余额时，自动向user_log表插入一条日志：
DELIMITER //
CREATE TRIGGER after_user_update
AFTER UPDATE ON user_info
FOR EACH ROW
BEGIN
-- 当余额发生变化时插入日志
IF NEW.balance != OLD.balance THEN
INSERT INTO user_log (user_id, log_content) VALUES (NEW.id, CONCAT('用户余额更新，原余额：', OLD.balance, '，新余额：', NEW.balance));
END IF;
END //
DELIMITER ;
再给user_log表的INSERT事件创建AFTER触发器，当插入日志时，自动更新日志表的统计标记（这里只是演示嵌套，实际业务按需设计）：
DELIMITER //
CREATE TRIGGER after_log_insert
AFTER INSERT ON user_log
FOR EACH ROW
BEGIN
-- 简单演示嵌套逻辑，实际可替换为业务需求
UPDATE user_log SET log_content = CONCAT(log_content, '，日志已记录') WHERE id = NEW.id;
END //
DELIMITER ;
现在执行更新用户余额的操作，观察嵌套效果：
-- 先插入一条测试用户数据
INSERT INTO user_info (username, balance) VALUES ('test_user', 100);
-- 更新用户余额，触发第一个触发器，第一个触发器的插入操作会触发第二个触发器
UPDATE user_info SET balance = 200 WHERE id = 1;
-- 查看日志表数据
SELECT * FROM user_log;
执行后会发现user_log表中不仅插入了余额更新的日志，日志内容还被第二个触发器追加了已记录的标记，说明两个触发器成功完成了嵌套执行。
触发器嵌套的限制与注意事项
递归嵌套的限制
如果是同一个触发事件递归触发，比如UPDATE触发器的操作又触发同一个表的UPDATE事件，默认是不允许的，会直接报错。如果需要开启递归，需要设置max_sp_recursion_depth的值：
-- 设置递归深度为2，允许最多2层递归嵌套 SET SESSION max_sp_recursion_depth = 2;
但是递归嵌套非常容易导致无限循环，比如一个UPDATE触发器更新同一张表的其他行，再次触发自身，很快就会导致递归深度超过限制，甚至拖垮数据库性能，所以非必要不建议使用递归嵌套。
性能与事务影响
触发器嵌套会增加数据库的操作链路，每一个嵌套的触发器都会增加执行耗时，如果嵌套层级过多，会导致单次DML操作的耗时大幅上升。同时所有触发器的操作会和原DML操作在同一个事务中，只要其中一个操作失败，整个事务都会回滚。
调试与维护难度
嵌套的触发器逻辑分散在不同的触发器中，出现数据异常时，排查问题需要逐层梳理触发链路，维护成本远高于在业务代码中实现相同逻辑。如果业务允许，建议优先在应用层实现复杂的关联逻辑，减少触发器的嵌套使用。
总结
MySQL是支持触发器嵌套的，非递归的跨表触发器嵌套默认就可以生效，递归嵌套需要调整系统变量开启。但嵌套使用会带来性能、维护等多方面的问题，开发者在使用前需要充分评估业务必要性，尽量控制嵌套层级，避免递归嵌套，同时做好相关的监控和异常处理，防止嵌套逻辑引发数据一致性问题。