嘿，我之前也碰到过一模一样的问题！咱们来一步步梳理最可能的原因和对应的解决办法：

1. 触发器触发了循环递归（最常见的坑） #

如果你写的是AFTER INSERT或AFTER UPDATE触发器，然后在触发器内部又执行了UPDATE Accounts SET account_type = 'cash' WHERE id = NEW.id这类操作，那大概率是触发了循环递归：

• 当你插入/更新非法类型的行时，AFTER触发器启动，执行UPDATE语句修正类型
• 这个UPDATE语句又会触发UPDATE触发器，再次执行相同的修正逻辑
• MySQL默认禁止触发器递归（max_sp_recursion_depth默认值为0），所以直接就会抛出异常终止操作。

解决办法：
把触发器改成BEFORE INSERT和BEFORE UPDATE类型，在数据真正写入/更新到表之前，直接修改NEW对象的字段值，不需要执行额外的UPDATE语句，示例代码如下：

DELIMITER //
CREATE TRIGGER fix_account_type_before_insert
BEFORE INSERT ON Accounts
FOR EACH ROW
BEGIN
    IF NEW.account_type NOT IN ('credit', 'checking', 'cash') THEN
        SET NEW.account_type = 'cash';
    END IF;
END //

CREATE TRIGGER fix_account_type_before_update
BEFORE UPDATE ON Accounts
FOR EACH ROW
BEGIN
    IF NEW.account_type NOT IN ('credit', 'checking', 'cash') THEN
        SET NEW.account_type = 'cash';
    END IF;
END //
DELIMITER ;

这种方式直接修改待写入的字段值，不会触发额外的更新操作，自然就不会有循环问题。

2. 表存在CHECK约束提前拦截了非法值 #

如果你的Accounts表之前添加了类似这样的CHECK约束：

ALTER TABLE Accounts ADD CONSTRAINT chk_account_type CHECK (account_type IN ('credit', 'checking', 'cash'));

MySQL的执行顺序是：BEFORE触发器 → 约束检查 → 执行插入/更新语句。如果你的触发器是AFTER类型，那约束检查会在触发器执行前先触发，直接报错；如果是BEFORE类型但逻辑写错了，没把非法值修正，约束检查也会失败。

解决办法：

• 如果你想保留CHECK约束，确保触发器是BEFORE类型，并且逻辑正确，能在约束检查前把非法值修正为合法值；
• 或者如果触发器已经能完全处理类型校验和修正，也可以直接删除这个CHECK约束，避免重复校验导致的冲突：

ALTER TABLE Accounts DROP CONSTRAINT chk_account_type;

3. 触发器内部的字段引用或逻辑错误 #

比如你在触发器里写错了字段名（比如表字段是account_type，但你写成了type），或者判断条件写反了（比如用了IN而不是NOT IN），导致非法值没有被修正，后续的操作（比如约束检查）就会报错。

解决办法：

• 核对触发器里的字段名和表结构是否完全一致；
• 手动测试触发器逻辑：插入一条非法类型的记录，查看最终写入Accounts表的数据是否被修正为cash，也可以在触发器里临时加日志输出（比如插入到一个测试表）来验证NEW对象的字段值是否被正确修改。

内容的提问来源于stack exchange，提问作者Manuel Guerra