MySQL触发器怎么用才靠谱，顺便聊聊几个实操案例和坑

说到MySQL触发器，它就像是你家小区的一个自动门卫，你不需要每次都去手动开门，只要满足特定条件，比如识别到车牌或者刷了门禁卡，门就自动开了，触发器也是这个道理，它是一段预先写好的代码，挂在某张表上，当这张表发生增（INSERT）、删（DELETE）、改（UPDATE）这些特定事件时,MySQL就会自动执行这段代码。

听起来很方便对吧？但用不好，这个“自动门卫”可能会给你乱开门，甚至把坏人放进来，怎么用才靠谱？核心就一句话：谨慎使用，简单至上。

为什么说要谨慎？因为它有“坑”。

最大的坑就是“隐形”，触发器是自动执行的，不像你写的业务代码，在程序里能一眼看到，如果团队里有人不知道某张表上挂了触发器，他可能只是执行了一个简单的更新操作，却意外触发了一连串复杂的逻辑，导致数据变得莫名其妙，排查起来非常头疼，这就像你在家里按了个灯开关，结果整个楼的电梯都停了,你根本想不到是这两件事有关联。

靠谱用的第一原则就是：做好文档和命名规范，比如给触发器起名时，就用 trg_[表名]_[after/before]_[insert/update/delete]_[用途] 这种格式，让人一眼就知道它是干嘛的，并且一定要在团队内部广而告之,或者在数据库设计文档里写清楚。

第二个坑是“性能”，触发器是放在数据库服务器上执行的，它会增加数据库的负担，如果一个触发器里的逻辑非常复杂，或者它挂在一张频繁被操作的表上（比如用户登录日志表），那每次操作都会触发一次复杂的计算，很可能成为系统的性能瓶颈。触发器里的逻辑一定要轻量，那些复杂的业务计算，能放在程序代码里做的,尽量就别塞给触发器。

第三个坑是“调试困难”，万一触发器里的SQL写错了，报错信息可能不会那么直观，你很难像调试程序一样一步步跟踪执行过程，这就要求我们写触发器时，代码要尽可能清晰、简单。

聊完了坑，我们看几个实操案例，感受一下它合适的应用场景。

自动记录数据变更日志（审计） 这是触发器最经典、也最靠谱的用途之一，比如你有一张非常核心的用户表，你想知道谁在什么时候修改了用户的余额，你不可能在每一个更新余额的业务代码里都手动写一条日志，那样太容易遗漏了。 这时候，可以创建一个 AFTER UPDATE 触发器：

CREATE TRIGGER trg_user_after_update_audit
AFTER UPDATE ON user_table
FOR EACH ROW
BEGIN
    IF OLD.balance != NEW.balance THEN
        INSERT INTO balance_audit_log (user_id, old_balance, new_balance, change_time, operator)
        VALUES (OLD.id, OLD.balance, NEW.balance, NOW(), CURRENT_USER);
    END IF;
END;

这个触发器的意思是：当user_table每次更新后，如果发现余额（balance）发生了变化，就往审计表balance_audit_log里自动插入一条记录，记下旧的余额、新的余额、变更时间和操作者，这样，所有余额变动都逃不过它的眼睛,非常可靠。

维护冗余数据的一致性 有时候为了查询效率，我们会在表里存一些冗余数据，比如在订单明细表里，除了单价和数量，还冗余了一个“小计”字段，为了保证这个“小计”永远等于单价乘以数量,可以用触发器来维护。

CREATE TRIGGER trg_order_item_before_insert_calculate
BEFORE INSERT ON order_item
FOR EACH ROW
BEGIN
    SET NEW.subtotal = NEW.unit_price * NEW.quantity;
END;

再写一个用于更新的：

CREATE TRIGGER trg_order_item_before_update_calculate
BEFORE UPDATE ON order_item
FOR EACH ROW
BEGIN
    IF NEW.unit_price != OLD.unit_price OR NEW.quantity != OLD.quantity THEN
        SET NEW.subtotal = NEW.unit_price * NEW.quantity;
    END IF;
END;

这样，无论在插入还是更新时，数据库都会自动帮你算好小计，业务代码根本不用关心这个计算逻辑,保证了数据的准确。

实现简单的级联操作（但需小心） MySQL本身支持外键的级联删除，但有时候规则更复杂，比如删除一个主分类时，你不想直接删除它下面的子分类，而是想把这些子分类挂到一个“未分类”的父节点下。

CREATE TRIGGER trg_category_before_delete_reassign
BEFORE DELETE ON main_category
FOR EACH ROW
BEGIN
    UPDATE sub_category SET parent_id = 0 WHERE parent_id = OLD.id;
END;

这个触发器在删除主分类之前执行，先把所有子分类的父ID重置为0（假设0是“未分类”的ID）。但这里有个大坑：这个UPDATE操作本身，会不会又触发sub_category表上的其他触发器？可能会造成意想不到的连锁反应，所以这种涉及多表的操作要格外小心,确保逻辑闭环。

触发器是个强大的工具，但它是一把双刃剑，把它想象成数据库里的“自动化脚本”，最适合干那些简单的、审计性的、与核心业务逻辑耦合度不高的脏活累活，千万别用它来实现复杂的业务规则，否则会让你的系统变得难以理解和维护，简单、透明、有文档,这样用触发器才最靠谱。

（参考来源：个人数据库开发经验、以及《高性能MySQL》一书中关于触发器和存储过程的谨慎使用建议）