MySQL 事务隔离级别与锁的高并发调整经验

在电商、金融、社交等业务中，高并发导致锁竞争、死锁甚至宕机已经成为日常痛点。这篇文章以“事务隔离级别”为主要。程序梳理锁类型与场景，并给出针对性的调整策略。

1️⃣ 事务隔离级别与锁的关系

四种标准隔离级别对应不同的锁行为：

• Read Uncommitted: 允许脏读，无任何锁；痛点：数据不一致导致业务错误。
• Read Committed: 仅使用行级共享/排他锁；痛点：仍可能出现不可重复读和幻读。
• Repeatable Read: MySQL 默认；行+间隙锁防幻读，但可能产生死锁；痛点：间隙锁导致高并发下等待时间拉长。
• Serializable: 强制行/表级排他锁；痛点：吞吐量骤降，适合极低并发。

主要选择合适的隔离级别是“先放大镜看问题”，而后用合适的 FOR UPDATE/行级操作才是真正“手段”。

关键锁类型一览

• S 锁: 多人可读，不阻塞写。
• X 锁: 写时独占。
• Gap Lock: 防止幻读，在 RR 中出现。
• I/Lock: 表层提示子行是否加了 X 或 S 锁。

2️⃣ 高并发常见热点 & 锁冲突场景分析 + 痛点提炼

`#5 优惠券领一次` 的完整代码示例 & 痛点剖析 sql -- 原始实现 BEGIN;SELECT id FROM user_coupon WHERE user_id=?AND coupon_id=?FOR UPDATE，INSERT INTO user_coupon VALUES;COMMIT，说起来，

- 两个请求同时到来 -> 两个 Gap Lock -> 死锁！- 前端请求被阻塞超时使用者体验崩溃。

`#5` 改进方案：

sql -- 推荐实现 INSERT INTO user_coupon VALUES ON DUPLICATE KEY UPDATE id=id;-- 或直接抛错捕获