能，mysql用signal、postgresql用raise exception在before update触发器中抛错可中断事务并回滚；必须与应用层原子update条件一致，且不可在after中使用。
触发器里不能直接阻止UPDATE执行，但能抛错中断事务
MySQL / PostgreSQL 的 BEFORE UPDATE 触发器无法像应用层那样“跳过扣减”，它只能检查条件、修改新值，或通过 SIGNAL（MySQL 5.5+）或 RAISE EXCEPTION（PostgreSQL）主动报错来终止当前语句。一旦触发器抛出异常，整个事务回滚，库存不会被错误更新。
常见错误是以为在触发器里写个 IF NEW.stock 就完事了——不抛错，UPDATE 照常执行，负库存照旧产生。
- MySQL 示例（需开启严格模式）：
DELIMITER $$ CREATE TRIGGER check_stock_before_update BEFORE UPDATE ON inventory FOR EACH ROW BEGIN IF NEW.stock - PostgreSQL 示例：
CREATE OR REPLACE FUNCTION prevent_negative_stock() RETURNS TRIGGER AS $$ BEGIN IF NEW.stock CREATE TRIGGER trg_prevent_neg_stock BEFORE UPDATE ON inventory FOR EACH ROW EXECUTE FUNCTION prevent_negative_stock();
触发器无法解决并发超卖，只防单次逻辑错误
触发器运行在单条 SQL 执行的上下文中，它看到的是“当前这一行即将变成什么值”，但看不到其他并发事务正在做的相同操作。比如两个并发 UPDATE inventory SET stock = stock - 1 WHERE id = 123，可能都读到 stock=1，都算出 new_stock=0，触发器检查时都是 ≥0，于是双双通过——结果 stock 变成 0，但实际应为 -1（如果没触发器就真变负了），而有触发器只是“侥幸”没负，但已丢失一次扣减。
也就是说，触发器能拦住明显错误（如手动 UPDATE 成 -5），但拦不住高并发下的竞争条件。
- 它适合兜底：防止应用层漏校验、SQL 脚本误操作、或调试时手抖写错值
- 它不适合主防线：不能替代
SELECT ... FOR UPDATE、乐观锁或 Redis 原子扣减 - 注意性能：每个 UPDATE 都要进触发器逻辑，高频写场景下会增加开销
真正起作用的，是把库存判断和扣减合并进一条原子语句
最可靠的做法不是靠触发器“事后检查”，而是让数据库引擎自己保证“查+改”不可分割。核心就是把库存是否足够的判断，直接写进 WHERE 子句。
例如：
UPDATE inventory SET stock = stock - 1 WHERE id = 123 AND stock >= 1;这条语句执行后，用
ROW_COUNT()（MySQL）或 GET DIAGNOSTICS（PostgreSQL）检查影响行数：若为 0，说明库存不足或已被扣走；若为 1，则成功。- 这个 WHERE 条件是原子的：InnoDB 在匹配行时会对满足条件的行加行锁，其他并发 UPDATE 会被阻塞或等待
- 不需要额外 SELECT，避免了“先查再更”的窗口期
- 必须确保
id字段有索引，否则可能升级为表锁 - 如果扣减量是变量（比如
quantity），要写成stock >= ?，而不是stock - ? >= 0（后者无法使用索引）
触发器 + 原子UPDATE + 应用层重试，才是完整链条
生产环境里，触发器只是最后一道保险。真正扛并发的，是原子 UPDATE 配合应用层对失败的处理逻辑。
典型流程是：
- 应用发起
UPDATE ... WHERE stock >= ? - 检查影响行数是否为 1；不是，则返回“库存不足”
- 若业务允许，可加简单重试（比如最多 3 次，带短延迟），应对瞬时竞争
- 同时在触发器里保留
SIGNAL或RAISE，防住那些绕过应用层直连数据库的异常路径（如 DBA 脚本、ETL 工具）
最容易被忽略的一点：触发器里的校验逻辑，必须和应用层、原子 UPDATE 的 WHERE 条件完全一致。比如应用层检查 stock >= quantity，触发器却只判 NEW.stock >= 0，那就会漏掉“扣 5 个但只剩 3 个”这种关键场景。
