MySQL触发器实战指南：何时用、怎么写、如何避坑
1. 项目概述：触发器不是“自动执行的魔法”，而是数据库层的精密守门人
你刚在MySQL里写完一条INSERT语句，数据啪一下进去了——但你有没有想过，这条记录刚落地的0.001秒内，数据库自己能不能悄悄做点别的事？比如自动生成一个日志、同步更新另一张统计表、甚至拦住一条明显违规的数据？这就是MySQL Triggers（触发器）真正发力的地方。它不依赖应用代码轮询或定时任务，而是在数据变更发生的最前线、最底层、毫秒级响应，把业务逻辑直接“焊”进数据库引擎内部。我做过十几个中大型系统，凡是涉及审计日志、库存扣减、积分同步、状态机流转这类强一致性要求的场景，触发器从来不是备选方案，而是第一道防线。它和你熟悉的INSERT、UPDATE、DELETE语句是同一层级的原生能力，但作用时机完全不同：INSERT是“我要写”，而BEFORE INSERT触发器是“你先别急着写，让我看看合不合适”。这种设计让很多原本需要应用层反复查、反复改、反复校验的逻辑，变成了一次性原子操作。尤其在高并发写入时，避免了应用层加锁带来的性能瓶颈和死锁风险。当然，它也不是万能胶——滥用会拖慢写入速度，调试困难，且跨库操作受限。所以这篇内容的核心，不是教你“怎么写语法”，而是带你搞懂：什么时候必须用它、什么时候绝对不能碰、写的时候哪几个参数决定成败、以及线上出问题时怎么三分钟定位到那行藏得最深的触发器代码。无论你是刚学SQL的新手，还是正在优化慢查询的老手，只要你的数据有“一动就牵全身”的特性，这篇就是为你量身写的实操手册。
2. 触发器的设计逻辑与核心选型依据
2.1 为什么不用应用层逻辑？——从一次库存超卖事故说起
去年双十一前压测，我们发现订单创建接口在峰值QPS 8000时，库存扣减出现0.3%的超卖。排查后发现，应用层的“查库存→判断是否足够→扣减”三步操作，在高并发下被多个请求同时穿透。虽然加了Redis分布式锁，但锁粒度太粗，导致吞吐量暴跌40%。最终解决方案，就是把这三步逻辑下沉到MySQL触发器里。关键在于：触发器的执行天然绑定在事务内，且由InnoDB引擎保证行级锁的自动获取。当两个请求同时对同一商品ID执行UPDATE inventory SET stock = stock - 1 WHERE id = 123时，InnoDB会自动对id=123这行加X锁，第二个请求必须等第一个事务提交后才能继续——这个过程完全透明，无需应用层任何干预。而应用层自己实现的锁，永远存在“锁失效窗口”：比如Redis锁过期时间设为10秒，但业务逻辑执行了12秒，锁就提前释放了。触发器没有这个概念，它的锁生命周期和SQL语句本身完全一致。所以，当你遇到“读-改-写”类操作（如库存、余额、计数器），且要求强一致性时，触发器不是“可选项”，而是“必选项”。但反过来说，如果逻辑涉及HTTP调用、文件读写、复杂计算（比如调用Python机器学习模型），那就绝对不能放触发器里——它会把整个事务拖死，让所有后续写入排队等待。
2.2 BEFORE vs AFTER：时机选择决定系统生死
触发器只有两种时机：BEFORE和AFTER。很多人以为“AFTER更安全，因为数据已经改完了”，这是致命误区。我亲眼见过三个生产事故，全因错误选择了AFTER。举个真实例子：某金融系统要求“用户余额低于100元时，自动冻结账户”。如果用AFTER UPDATE触发器：
CREATE TRIGGER check_balance_after AFTER UPDATE ON users FOR EACH ROW BEGIN IF NEW.balance < 100 THEN UPDATE users SET status = 'frozen' WHERE id = NEW.id; END IF; END;表面看没问题，但实际运行时会报错：Can't update table 'users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.—— MySQL禁止在AFTER触发器里修改触发它的同一张表。而换成BEFORE触发器，就能在数据写入前直接干预：
CREATE TRIGGER check_balance_before BEFORE UPDATE ON users FOR EACH ROW BEGIN IF NEW.balance < 100 THEN SET NEW.status = 'frozen'; -- 直接修改NEW对象，影响即将写入的值 END IF; END;这里的关键原理是：BEFORE触发器拿到的是“待写入的新值”（NEW）和“旧值”（OLD）的副本，你可以任意修改NEW中的字段，这些修改会覆盖原始SQL语句的值；而AFTER触发器拿到的是已写入磁盘的最终值，此时再想改原表，引擎会认为你在破坏事务隔离性。所以简单记：要修改当前行数据，必须用BEFORE；要记录日志、通知其他系统、更新统计表，才用AFTER。另外，INSERT操作没有OLD值（因为没旧数据），DELETE操作没有NEW值（因为新数据就是NULL），这个细节在写条件判断时经常被忽略，导致触发器逻辑失效。
2.3 FOR EACH ROW：为什么不能写成FOR EACH STATEMENT？
MySQL触发器只支持ROW级别，不支持STATEMENT级别（像Oracle那样）。这意味着每条INSERT/UPDATE/DELETE语句影响多少行，触发器就执行多少次。有人抱怨“我一条INSERT INTO orders SELECT ... FROM temp_orders插入10万行，触发器执行了10万次，太慢了”，然后试图找STATEMENT级替代方案——这是方向性错误。ROW级恰恰是优势所在：它保证了每一行的处理都是独立、可预测的。比如你要给每条新订单生成唯一流水号，用ROW级可以这样写：
CREATE TRIGGER gen_order_no BEFORE INSERT ON orders FOR EACH ROW BEGIN SET NEW.order_no = CONCAT('ORD', DATE_FORMAT(NOW(), '%Y%m%d'), LPAD(@row_id := @row_id + 1, 6, '0')); END;而如果强行用STATEMENT级，你根本无法保证10万行的流水号不重复（因为并发INSERT时，@row_id变量会被多个会话覆盖）。所以，当看到“批量插入慢”时，真正的优化点不在触发器类型，而在是否真的需要每行都触发。比如审计日志，完全可以改成：在应用层批量生成日志记录，最后用单条INSERT写入log表，而不是让触发器为每行订单都INSERT一次日志——后者IO开销呈线性增长，前者是常数级。我在线上环境实测过：10万行订单插入，带行级日志触发器耗时23秒；改为应用层批量日志后，降到1.8秒。所以选型的核心不是“语法支持什么”，而是“业务本质需要什么”。
3. 核心语法解析与实操避坑指南
3.1 完整语法结构拆解：从CREATE到DELIMITER的每一个字符
MySQL触发器的完整语法看似简单，但每个符号都有不可替代的作用。我们以一个生产环境真实使用的库存检查触发器为例，逐段解析：
DELIMITER $$ CREATE TRIGGER inventory_check_before_insert BEFORE INSERT ON order_items FOR EACH ROW BEGIN DECLARE current_stock INT DEFAULT 0; SELECT stock INTO current_stock FROM products WHERE id = NEW.product_id FOR UPDATE; IF current_stock < NEW.quantity THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient stock for product'; END IF; END$$ DELIMITER ;DELIMITER $$：这是最关键的前置动作。MySQL默认用分号;作为语句结束符，但触发器体内的BEGIN...END块里也有分号，如果不改分隔符，MySQL会在第一个分号就报错“语法错误”。$$只是临时分隔符，你可以用//、@#等任意字符串，但必须和结尾的DELIMITER ;配对。我见过太多人漏写这行，或者结尾忘了还原分隔符，导致后续所有SQL都执行失败。CREATE TRIGGER trigger_name：触发器名必须全局唯一，建议按表名_操作_时机_功能命名，比如order_items_insert_before_stock_check。名字太短（如chk1）在线上排查时会让你抓狂。BEFORE INSERT ON order_items：时机+事件+表名，顺序不能错。注意INSERT不区分INSERT INTO t VALUES()和INSERT INTO t SELECT，都会触发。FOR EACH ROW：强制声明，不可省略。DECLARE current_stock INT DEFAULT 0;：变量声明必须在BEGIN后第一行。DEFAULT 0很重要——如果SELECT没查到数据，current_stock会是NULL，而NULL < 5的结果是UNKNOWN，IF判断会跳过，导致检查失效。所以必须初始化为确定值。SELECT ... INTO ... FROM ... FOR UPDATE：这是库存检查的核心。FOR UPDATE给products表对应行加写锁，防止并发扣减时超卖。漏掉这个，触发器就失去意义。SIGNAL SQLSTATE '45000'：抛出自定义异常。45000是通用错误码，MESSAGE_TEXT内容会原样返回给应用层。不要用SELECT 'error'这种无效方式，它不会中断执行。
提示：触发器内不能使用
COMMIT、ROLLBACK、START TRANSACTION等事务控制语句，否则直接报错。它的事务上下文完全继承自外部SQL语句。
3.2 NEW和OLD对象的深度用法：不只是取值，更是改值
NEW和OLD是触发器的两大核心对象，但90%的人只用它们来“读”，却不知道“写”才是精髓。先说读取：在BEFORE INSERT中，OLD为空；AFTER INSERT中，OLD为空，NEW为插入后的完整行；BEFORE UPDATE中，OLD是更新前的值，NEW是更新后的值（可修改）；AFTER DELETE中，OLD是删除前的值，NEW为空。重点在“写”：
- BEFORE INSERT中修改NEW：可以动态生成字段值。比如自动生成UUID：
SET NEW.id = UUID(); -- 覆盖应用层传入的id - BEFORE UPDATE中修改NEW：实现字段自动更新。比如更新用户邮箱时，自动转小写防重复：
SET NEW.email = LOWER(NEW.email); - BEFORE DELETE中修改OLD？不行！OLD是只读的，试图
SET OLD.name = 'xxx'会报错。这是MySQL的硬性限制，因为删除操作不需要“改旧值”。
一个经典陷阱：在BEFORE UPDATE触发器里，你以为SET NEW.updated_at = NOW()就够了，但如果你的应用层SQL本身写了UPDATE users SET name='a', updated_at='2023-01-01' WHERE id=1，那么NEW.updated_at的初始值就是'2023-01-01'，你的SET语句会覆盖它。但如果你希望“应用层没指定updated_at时才自动填充”，就得加判断：
IF NEW.updated_at IS NULL THEN SET NEW.updated_at = NOW(); END IF;注意：NEW和OLD里的字段名，必须和表结构完全一致（包括大小写）。MySQL在Linux下表名区分大小写，触发器里写错大小写会导致
Unknown column错误，且错误提示极其隐蔽。
3.3 权限与安全边界：为什么root能用，普通用户却报错
触发器的创建和执行权限是分离的。创建触发器需要TRIGGER权限，而执行触发器时，MySQL会检查触发器内SQL语句所需的权限。比如上面的库存检查触发器里有SELECT FROM products和UPDATE products，那么执行INSERT order_items的用户，必须同时拥有对products表的SELECT和UPDATE权限。我遇到过最典型的案例：DBA用root创建了触发器，应用连接用的是app_user账号，结果上线后所有订单插入都失败，错误是Access denied for user 'app_user'@'%' to database 'shop'。排查半天才发现，app_user只有order_items表的INSERT权限，没有products表的任何权限。解决方案有两个：一是给app_user加上必要权限（推荐）；二是用SQL SECURITY DEFINER让触发器以定义者权限执行：
CREATE DEFINER = 'root'@'localhost' SQL SECURITY DEFINER TRIGGER ...这样触发器内的SELECT/UPDATE就用root权限执行，app_user只需有触发器所在表的DML权限即可。但要注意：DEFINER权限过高有安全风险，必须确保触发器代码绝对可信，否则可能被利用提权。
4. 实操全流程：从零搭建一个防刷单的订单触发器
4.1 需求分析与表结构准备
我们要实现的功能是：同一用户10分钟内下单超过5次，自动将后续订单状态设为'pending_review'，交由人工审核。这属于典型的风控场景，必须在数据库层拦截，不能依赖应用层缓存（缓存可能丢失或不同步）。首先确认表结构：
-- 用户表 CREATE TABLE users ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL ); -- 订单表 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, amount DECIMAL(10,2) NOT NULL, status ENUM('created','paid','shipped','completed','pending_review') DEFAULT 'created', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_created (user_id, created_at) ); -- 插入测试数据 INSERT INTO users (username) VALUES ('alice'), ('bob'); INSERT INTO orders (user_id, amount, created_at) VALUES (1, 99.99, '2023-10-01 10:00:00'), (1, 199.99, '2023-10-01 10:01:00'), (1, 299.99, '2023-10-01 10:02:00'), (1, 399.99, '2023-10-01 10:03:00'), (1, 499.99, '2023-10-01 10:04:00'), (1, 599.99, '2023-10-01 10:05:00'); -- 这是第6单，应被标记为pending_review关键点：idx_user_created索引必不可少。因为触发器里要查“该用户最近10分钟订单数”，没有这个联合索引，每次INSERT都要全表扫描orders表，性能直接崩盘。我在线上环境实测过，1000万订单表，没索引时触发器平均耗时2.3秒；加索引后降到8毫秒。
4.2 触发器代码编写与逐行注释
DELIMITER $$ CREATE TRIGGER anti_fraud_order_before_insert BEFORE INSERT ON orders FOR EACH ROW BEGIN -- 声明变量存储近10分钟订单数 DECLARE recent_order_count INT DEFAULT 0; -- 查询该用户在10分钟内的订单数量 -- 注意：用BETWEEN比用>= AND <=更易读，且MySQL能更好利用索引 SELECT COUNT(*) INTO recent_order_count FROM orders WHERE user_id = NEW.user_id AND created_at BETWEEN DATE_SUB(NOW(), INTERVAL 10 MINUTE) AND NOW(); -- 如果订单数>=5，将新订单状态设为pending_review -- 这里用>=5是因为当前INSERT是第N+1单，查出来5单意味着这是第6单 IF recent_order_count >= 5 THEN SET NEW.status = 'pending_review'; END IF; END$$ DELIMITER ;这段代码的精妙之处在于：
DATE_SUB(NOW(), INTERVAL 10 MINUTE)：用函数计算时间范围，比拼接字符串（如CONCAT(DATE(NOW()), ' ', TIME(NOW()))）更高效，且能走索引。BETWEEN ... AND ...：MySQL对BETWEEN的优化比>= AND <=更好，尤其是在有索引时。COUNT(*)：比COUNT(id)稍快，因为不需检查字段是否为NULL。- 没有加
FOR UPDATE：因为这里只是读操作，不需要锁行，加了反而降低并发。
4.3 测试验证与结果分析
现在执行第6单插入：
INSERT INTO orders (user_id, amount) VALUES (1, 699.99); SELECT * FROM orders WHERE user_id = 1 ORDER BY created_at DESC LIMIT 1;结果：
+----+---------+--------+----------------+---------------------+ | id | user_id | amount | status | created_at | +----+---------+--------+----------------+---------------------+ | 7 | 1 | 699.99 | pending_review | 2023-10-01 10:05:00 | +----+---------+--------+----------------+---------------------+成功！再插入第7单：
INSERT INTO orders (user_id, amount) VALUES (1, 799.99); -- 查看最新一条 SELECT * FROM orders WHERE user_id = 1 ORDER BY created_at DESC LIMIT 1;结果同样是pending_review。证明触发器持续生效。
但注意一个边界情况：如果用户在10:00:00下了第1单，10:09:59下了第5单，那么10:10:00下的第6单，DATE_SUB(NOW(), INTERVAL 10 MINUTE)会算到10:00:00，BETWEEN包含起止时间，所以第1单仍被计入，总数还是5，第6单仍被拦截。这是符合需求的——“10分钟滚动窗口”，不是“每10分钟重置”。
4.4 性能压测与优化实录
用sysbench模拟并发插入，对比有无触发器的TPS：
- 环境：MySQL 8.0.32，16核32G，SSD
- 场景：100个线程并发INSERT orders
- 结果：
触发器状态 平均TPS 95%延迟(ms) CPU使用率 无触发器 12500 8.2 45% 有触发器 8900 12.7 68%
性能下降约29%，在可接受范围。但如果把时间窗口从10分钟改成1小时，TPS会暴跌到3200——因为BETWEEN范围扩大，索引扫描行数指数级增长。优化方案：
- 方案1（推荐）：增加覆盖索引，只查count，不回表：
这样ALTER TABLE orders ADD INDEX idx_user_created_status (user_id, created_at, status);COUNT(*)可以直接从索引B+树叶子节点统计，无需访问主键聚簇索引。 - 方案2：用Redis缓存用户最近订单数，触发器里先查Redis，命中则直接判断，未命中再查DB并回填。但这引入了缓存一致性问题，适合对实时性要求不高的场景。
我最终采用方案1，压测后TPS回升到10200，95%延迟降到10.1ms，CPU降至58%。这说明：触发器性能瓶颈90%来自SQL查询效率，而非触发器本身。
5. 常见问题排查与线上故障速查表
5.1 “触发器没生效”——90%是这五个原因
线上最常被问的问题：“我写了触发器，但INSERT后数据没变，日志也没输出”。根据我的经验，按概率排序如下：
| 排查顺序 | 常见原因 | 快速验证方法 | 解决方案 |
|---|---|---|---|
| 1 | 触发器名重复或语法错误 | SHOW TRIGGERS LIKE 'orders';查看是否存在，状态是否为ACTIVE | 用DROP TRIGGER IF EXISTS trigger_name;删除重装，注意DELIMITER |
| 2 | 事件类型不匹配 | 检查触发器是BEFORE INSERT，但你执行的是REPLACE INTO或INSERT IGNORE | REPLACE会触发DELETE+INSERT，INSERT IGNORE在冲突时不会触发BEFORE INSERT（但会触发AFTER INSERT） |
| 3 | NEW/OLD字段名错误 | DESCRIBE orders;确认字段名大小写和拼写 | 字段名必须和DESC结果完全一致，Linux下user_id≠User_ID |
| 4 | 权限不足 | 用触发器所属用户登录，手动执行触发器内SQL（如SELECT COUNT(*) FROM orders WHERE user_id=1） | 给执行用户授予对应表的SELECT/UPDATE权限，或改用SQL SECURITY DEFINER |
| 5 | 事务被回滚 | 在触发器里加INSERT INTO debug_log VALUES (NOW(), 'trigger_executed');，看日志表是否有记录 | 如果日志有记录但主表没数据，说明外部事务ROLLBACK了，触发器执行了但被一起回滚 |
特别提醒：INSERT IGNORE和ON DUPLICATE KEY UPDATE对触发器的影响极易混淆。INSERT IGNORE在遇到唯一键冲突时，不执行BEFORE INSERT，但会执行AFTER INSERT（因为MySQL认为“插入成功了，只是没写新行”）；而ON DUPLICATE KEY UPDATE会正常触发BEFORE INSERT和AFTER INSERT。所以如果你的触发器逻辑依赖BEFORE阶段，千万别用INSERT IGNORE。
5.2 “触发器报错导致整个事务失败”——如何优雅降级
生产环境最怕触发器里一个SIGNAL就把整个业务流程卡死。比如库存检查触发器抛出异常，导致用户下单页面显示“数据库错误”，体验极差。解决方案是：用条件判断+日志记录代替硬性阻断。改造库存触发器：
CREATE TRIGGER inventory_check_before_insert_fallback BEFORE INSERT ON order_items FOR EACH ROW BEGIN DECLARE current_stock INT DEFAULT 0; DECLARE insufficient BOOLEAN DEFAULT FALSE; SELECT stock INTO current_stock FROM products WHERE id = NEW.product_id FOR UPDATE; IF current_stock < NEW.quantity THEN SET insufficient = TRUE; -- 不用SIGNAL，改为写日志表，并设置状态 INSERT INTO inventory_alerts (product_id, required, available, created_at) VALUES (NEW.product_id, NEW.quantity, current_stock, NOW()); END IF; -- 关键：只在充足时才扣减，不足时不干预，由应用层处理 IF NOT insufficient THEN UPDATE products SET stock = stock - NEW.quantity WHERE id = NEW.product_id; END IF; END;这样，即使库存不足，INSERT order_items依然成功，只是products表没扣减。应用层收到成功响应后，再查inventory_alerts表，发现有告警，就返回“库存不足”给用户。用户体验从“系统错误”变成“业务提示”，投诉率直降70%。
5.3 “触发器递归调用”——那个让你重启MySQL的隐形炸弹
MySQL默认禁用触发器递归（max_sp_recursion_depth=0），但有些场景会意外触发。比如：
- 表A的BEFORE UPDATE触发器更新了表B
- 表B的AFTER UPDATE触发器又更新了表A 这就形成循环。MySQL会报错
Recursive stored function or trigger call not allowed，但更可怕的是，如果触发器里有INSERT INTO log_table，而log_table也有触发器，就可能无限嵌套直到栈溢出。
排查命令：
-- 查看所有触发器及其定义 SELECT TRIGGER_NAME, EVENT_MANIPULATION, EVENT_OBJECT_TABLE, ACTION_TIMING, ACTION_STATEMENT FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'your_db'; -- 查看触发器内是否包含UPDATE/INSERT其他表的语句根治方法：
- 原则：一个触发器只操作一张表（自身表除外），所有跨表逻辑移到应用层或存储过程。
- 兜底：在触发器开头加递归防护：
DECLARE recursion_guard INT DEFAULT 0; SELECT @recursion_guard INTO recursion_guard; IF recursion_guard = 1 THEN LEAVE proc_label; -- 直接退出 END IF; SET @recursion_guard = 1; -- ... 主逻辑 ... SET @recursion_guard = 0;
这个变量是会话级的，不影响其他连接，安全可靠。
6. 进阶技巧与生产环境最佳实践
6.1 触发器与分区表协同：百万级日志表的自动归档
当订单量达到日均百万，order_items表会迅速膨胀。我们用Range分区按月拆分，但分区维护（如ALTER TABLE ... DROP PARTITION）需要DBA手动操作。用触发器+事件调度器实现全自动：
-- 创建分区维护触发器（在每月1号凌晨触发） DELIMITER $$ CREATE EVENT auto_partition_maintain ON SCHEDULE EVERY 1 MONTH DO BEGIN DECLARE next_month_start DATE; SET next_month_start = DATE_ADD(LAST_DAY(NOW()), INTERVAL 1 DAY); -- 为下个月添加新分区 SET @sql = CONCAT('ALTER TABLE order_items ADD PARTITION (PARTITION p', DATE_FORMAT(next_month_start, '%Y%m'), ' VALUES LESS THAN (\'', DATE_FORMAT(DATE_ADD(next_month_start, INTERVAL 1 MONTH), '%Y-%m-01'), '\'))'); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; -- 删除3个月前的分区（保留最近3个月） SET @old_month = DATE_FORMAT(DATE_SUB(NOW(), INTERVAL 3 MONTH), '%Y%m'); SET @sql = CONCAT('ALTER TABLE order_items DROP PARTITION p', @old_month); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt; END$$ DELIMITER ;注意：事件调度器必须开启（SET GLOBAL event_scheduler = ON;），且触发器名不能和现有分区名冲突。这个方案让DBA彻底告别每月初的手动分区维护。
6.2 调试技巧：如何在不改代码的情况下监控触发器
生产环境不能随便加SELECT或INSERT INTO debug_log，会影响性能。MySQL提供原生调试手段：
- 启用通用查询日志（临时）：
日志里会显示触发器执行的每条SQL，包括SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/log/mysql/general.log'; -- 执行测试SQL，然后立刻关掉 SET GLOBAL general_log = 'OFF';SELECT和UPDATE。 - 用Performance Schema追踪：
这能精确看到触发器平均耗时、执行次数，无需侵入式修改。-- 开启相关instrument UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'statement/sql/%trigger%'; -- 查看触发器执行统计 SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%trigger%';
6.3 替代方案对比：触发器 vs 应用层 vs 其他数据库特性
当需求浮现时，先问自己：这真的是触发器的主场吗？对比三种主流方案：
| 方案 | 适用场景 | 优点 | 缺点 | 我的选择建议 |
|---|---|---|---|---|
| MySQL触发器 | 强一致性要求、读-改-写原子操作、审计日志、状态自动流转 | 数据库原生、事务内原子、无需应用层改造 | 调试困难、性能敏感、逻辑复杂时难维护 | 首选：库存、余额、积分等资金/资源类操作 |
| 应用层逻辑 | 业务逻辑复杂（需调用API、发消息）、跨服务、需异步处理 | 灵活、易测试、可观测性强、可灰度 | 存在竞态条件、需额外加锁、网络开销 | 首选：发送短信、调用风控服务、生成PDF等IO密集型操作 |
| 物化视图/汇总表 | 实时统计（如“用户总消费额”）、报表查询优化 | 查询极快、数据一致性由MySQL保证 | 占用存储、写入稍慢、MySQL原生不支持（需用汇总表模拟） | 折中：用定时任务+INSERT ... SELECT每日汇总，触发器只负责增量更新 |
最后分享一个血泪教训：曾有个项目，用触发器实现“订单支付后，自动给用户发优惠券”。上线后发现优惠券发放量是订单量的3倍。排查发现，支付系统有重试机制，同一笔订单会多次调用UPDATE orders SET status='paid'，每次都会触发AFTER UPDATE触发器。正确做法是：在触发器里加幂等判断，只在status从'created'变为'paid'时才发券：
IF OLD.status = 'created' AND NEW.status = 'paid' THEN -- 发券逻辑 END IF;这个if判断，救了我们整整27万张不该发的优惠券。所以，写触发器的第一条铁律：永远假设你的SQL会被重复执行。