mysql如何利用事务隔离级别解决特定业务冲突_mysql隔离方案选型-mysql教程-PHP中文网

事务隔离级别需按场景精准选择：repeatable read防不住库存扣减中的幻读，serializable性能差，read committed仍可能触发间隙锁；应优先用select ... for update显式加锁，并配合唯一约束+重试处理幻读。

mysql如何利用事务隔离级别解决特定业务冲突_mysql隔离方案选型

事务隔离级别选错，脏读幻读不是bug是配置

MySQL 默认的 REPEATABLE READ 看似稳妥，但对“库存扣减+下单”这类强一致性场景，它防不住幻读——比如两个事务同时查到库存 10，都通过校验，然后都执行 UPDATE inventory SET stock = stock - 1，结果变成 8 而非预期的 9。这不是代码写错了，是隔离级别没压住并发语义。

真正起作用的不是“设得高”，而是“设得准”：

READ UNCOMMITTED 基本不用，连未提交变更都能读，业务逻辑大概率崩
READ COMMITTED 能防脏读，适合日志归档、报表统计等允许“读到中间态”的场景；但在库存类操作中，两次 SELECT 可能返回不同结果，导致校验失效
REPEATABLE READ 是 InnoDB 默认，可重复读，但幻读靠间隙锁（gap lock）模拟，一不小心就锁表或死锁
SERIALIZABLE 最严，所有 SELECT 隐式加共享锁，写操作阻塞读，吞吐暴跌，仅适合极低频关键核对（如财务对账）

用 SELECT ... FOR UPDATE 而不是单纯调高隔离级别

很多人以为把隔离级别提到 SERIALIZABLE 就万事大吉，其实更可靠、更轻量的做法是在关键路径显式加锁。比如扣库存前，用 SELECT stock FROM inventory WHERE id = 123 FOR UPDATE，这条语句会在索引记录上加行锁（如果条件走索引），后续同 key 的更新必须等待。

注意几个实际坑点：

没走索引？FOR UPDATE 会升级为表锁，整个表卡住
WHERE 条件含函数或隐式转换（如 WHERE sku_id = '123' 但字段是 INT），索引失效，照样锁全表
事务里先 SELECT ... FOR UPDATE，再做其他无关查询，可能延长锁持有时间，增加冲突概率
应用层没捕获 Lock wait timeout exceeded 错误，直接报 500，用户感知就是“下单失败”，而非重试

幻读真实发生时，别硬扛，换唯一约束+重试

比如“防止重复下单”，用 SELECT ... FOR UPDATE 查订单是否存在，再插入，看似闭环，但两个事务查完都没单，都去插，唯一索引冲突后一个失败——这就是幻读在作祟。这时靠隔离级别解决成本高（SERIALIZABLE 太重），靠锁又难覆盖所有路径。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

更务实的做法是：依赖数据库唯一约束，配合应用层重试

给业务单号字段加 UNIQUE 索引（如 order_no）
插入时用 INSERT INTO orders (...) VALUES (...) ON DUPLICATE KEY UPDATE updated_at = NOW()，或直接捕获 1062 Duplicate entry 错误
捕获到冲突后，立刻 SELECT 刚插的单号，确认是否真存在，再决定是返回已有订单，还是报错
别在事务里做网络请求或耗时计算，否则锁持有时间不可控

READ COMMITTED 下的间隙锁行为容易被低估

很多人以为切到 READ COMMITTED 就彻底关了间隙锁，其实 InnoDB 在该级别下仍会对唯一索引的等值查询（WHERE id = ?）加记录锁，但**不加间隙锁**；而范围查询（WHERE id > 100）依然可能触发间隙锁，尤其配合 INSERT ... SELECT 或 UPDATE ... WHERE 时。

这意味着：即使你用了 READ COMMITTED，只要 SQL 没走唯一索引、或者用了范围条件，照样可能锁住不该锁的区间，引发阻塞。