mysql触发器中禁止select…into查询当前表,应冗余阈值字段或由应用层配置;告警需异步处理,触发器仅写入log表,由外部任务批量执行;须用after update确保原子性,避免并发误判。

触发器里不能用 SELECT … INTO 变量来查库存阈值
很多开发者想在 BEFORE UPDATE 触发器里先查当前商品的预警值(比如 low_stock_threshold 字段),再和新库存比对,结果报错 Can't update table 'products' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。MySQL 不允许触发器里对当前表做 SELECT(尤其带 INTO 变量时),哪怕只是读取。
解决办法是把阈值字段冗余进 products 表本身(如加 min_stock INT DEFAULT 5),或改用 NEW.min_stock 直接参与判断——前提是这个值已存在且业务逻辑允许它被写死或由上游维护。
- 不要在触发器里写
SELECT min_stock FROM products WHERE id = NEW.product_id INTO @threshold - 把预警阈值作为
products表的一个列,随主数据一起维护 - 如果阈值需动态配置,改用应用层查配置表 + 手动补货通知,别硬塞进触发器
INSERT/UPDATE 后发告警必须用异步方式,别直接调 HTTP 或发邮件
触发器内禁止执行耗时操作:curl、SMTP、外部 API 调用都会导致事务卡住甚至超时失败。MySQL 触发器只适合做轻量、确定性动作,比如写日志表、更新关联字段。
正确做法是:触发器只往一张 stock_alert_log 表插入记录,由外部定时任务(如每分钟跑一次的 Python 脚本)轮询该表,批量处理告警(发钉钉、写 Kafka、调 ERP 接口)。
- 建表:
CREATE TABLE stock_alert_log (id BIGINT AUTO_INCREMENT, product_id INT, current_stock INT, created_at DATETIME DEFAULT NOW(), handled TINYINT DEFAULT 0) - 触发器里只做:
INSERT INTO stock_alert_log (product_id, current_stock) VALUES (NEW.id, NEW.stock) - 绝不出现
SHELL、sys_exec、HTTP_CLIENT等扩展函数(即使装了也极不推荐)
AFTER INSERT 和 AFTER UPDATE 的选择影响预警时效性
用 AFTER UPDATE 没问题,但注意:如果订单扣减库存是通过 UPDATE products SET stock = stock - 1 WHERE id = ? 实现,那么触发器看到的是最终值,能准确判断是否跌破阈值;但如果扣减逻辑是先查再算再更新(非原子),可能因并发导致误判。
更稳妥的是统一用 AFTER UPDATE,并确保库存变更全部走原子 SQL(如 UPDATE ... SET stock = stock - ? WHERE id = ? AND stock >= ?),失败则回滚。这样触发器拿到的 NEW.stock 是真实生效后的值。
- 避免在
BEFORE触发器里修改NEW.stock来“拦截”扣减——这会让业务逻辑和数据库耦合过紧 - 不要监听
INSERT,新品上架一般不触发预警,除非初始化库存就低于阈值 - 若支持预售或虚拟库存,得额外加字段标记类型,触发器里跳过这类商品
测试时容易漏掉并发场景下的重复告警
单条订单扣减触发一次预警,但高并发下多个线程同时把库存从 6 降到 4,每个都满足 NEW.stock ,就会写入多条 <code>stock_alert_log 记录,导致重复通知。
解决方案不是在触发器里加锁(不可行),而是靠应用层去重:轮询脚本查 stock_alert_log 时,按 product_id 分组,只取 MAX(created_at) 的那条未处理记录;或者加唯一索引 UNIQUE KEY uk_product_unhandled (product_id) WHERE handled = 0(MySQL 8.0+ 支持函数索引,否则用生成列)。
- 触发器本身无法感知其他并发事务是否已触发相同告警
- 去重必须放在下游消费端,不能指望数据库自动 dedup
- 日志表记得定期归档,不然
stock_alert_log会越积越大
真正难的不是写几行 CREATE TRIGGER,而是让预警既不漏、也不重、还不拖慢主交易链路。库存字段一变就写日志表,其余全交给外部服务,这个边界划清楚了,后面才好运维。











