最稳妥的做法是在before update触发器中直接判断new.stock是否小于0；不能依赖old.stock减扣减值，因扣减量来源不确定且可能被其他逻辑覆盖，必须以即将写入的new.stock为准。
触发器里怎么判断库存即将变负
直接在 BEFORE UPDATE 触发器中比较 NEW.stock 和扣减量，是最稳妥的做法。不能依赖 OLD.stock 减去业务传入的扣减值——因为扣减量可能来自任意字段（比如 order_amount），也可能被其他逻辑修改过，必须以实际要写入的 NEW.stock 为准。
常见错误是写成：IF OLD.stock - 10 —— 这假设每次只扣 10，但触发器必须通用，且无法预知扣多少。
正确做法是：明确知道本次更新目标值，直接检查它是否小于 0：
DELIMITER $$ CREATE TRIGGER check_stock_before_update BEFORE UPDATE ON products FOR EACH ROW BEGIN IF NEW.stock <h3>为什么不能用 AFTER UPDATE + ROLLBACK</h3><p><code>AFTER UPDATE</code> 触发器无法阻止写入——数据已经落盘。此时再抛异常，MySQL 会报错，但事务未必回滚（尤其在非事务引擎如 MyISAM 下完全无效）；即使 InnoDB 中能回滚，也属于“事后补救”，违反了约束前置原则，还可能引发并发问题（比如两个并发请求同时读到足够库存，都通过校验，然后先后写入导致超卖）。</p><p>所以必须用 <code>BEFORE UPDATE</code>，在变更发生前拦截。</p>
- 触发时机必须是
BEFORE，不是AFTER - 引擎必须是
InnoDB（支持事务和行锁），MyISAM不适用 - 不能靠应用层二次查库存做判断，那是竞态根源
扣减逻辑分散在多张表时怎么统一校验
如果订单、发货、调拨等操作分别更新 products、warehouse_stock、shop_inventory 等不同表，就无法靠单个触发器覆盖全部场景。这时触发器只能守住「本表」底线，比如确保 products.stock 永远不为负，但无法防止 warehouse_stock 被单独扣成负数。
真正可靠的方案是：把库存扣减封装成存储过程，强制所有业务路径调用它：
DELIMITER $$ CREATE PROCEDURE deduct_stock(IN p_product_id INT, IN p_amount INT) BEGIN DECLARE current_stock INT DEFAULT 0; START TRANSACTION; SELECT stock INTO current_stock FROM products WHERE id = p_product_id FOR UPDATE; IF current_stock <p>触发器适合守单一表的底线，跨表/跨业务的一致性得靠上层协调或存储过程。</p><h3>触发器抛出的错误在应用里怎么捕获</h3><p>MySQL 触发器用 <code>SIGNAL</code> 抛出的异常，在应用层会表现为具体数据库驱动的异常类型，比如 Python 的 <code>pymysql.err.IntegrityError</code>，Java 的 <code>SQLException</code> 且 <code>getSQLState()</code> 返回 <code>"45000"</code>。</p><p>关键点：</p>
- 不要只 catch 通用
Exception，要识别SQLSTATE '45000'或自定义错误码 - 应用需区分这是业务拒绝（库存不足）还是系统故障（连接超时），前者应返回用户友好提示，后者才需重试或告警
- 避免在触发器里写日志表（比如 INSERT INTO log_table），可能引发死锁或性能抖动
触发器本身不处理重试、补偿或通知，它只做一件事：在数据写入前说“不行”。剩下的事，得由调用方想清楚。
