MySQL并发控制核心是锁机制与事务隔离级别协同，通过行锁、间隙锁、临键锁、意向锁及MVCC实现一致性与高性能；不同隔离级别决定锁范围与时间，InnoDB默认REPEATABLE READ配合临键锁防幻读，MVCC支持非阻塞快照读，死锁由等待图主动检测并回滚。
MySQL 的并发控制机制核心在于锁机制与事务隔离级别的协同作用，目的是在保证数据一致性的前提下，尽可能提升并发性能。理解它不能只看“加什么锁”，更要清楚“什么时候加、加在哪、为什么加、不加会怎样”。
锁的类型与粒度：从行到表，按需选择
MySQL（以 InnoDB 为例）支持多种锁，关键区别在于作用范围和冲突强度：
- 行级锁（Record Lock）：锁定索引记录本身，是并发性能最优的选择。但前提是查询能走索引——全表扫描会退化为锁表或锁多个间隙。
-
间隙锁（Gap Lock）：锁定索引记录之间的“空隙”，防止幻读。仅在 REPEATABLE READ 及以上隔离级别、且使用范围条件（如
WHERE id BETWEEN 10 AND 20）时生效。 - 临键锁（Next-Key Lock）：行锁 + 间隙锁的组合，InnoDB 默认使用的锁算法，用于解决幻读问题。
- 意向锁（Intention Lock）：表级锁，只是“声明”，表示事务将要在某行上加 X/S 锁。它不阻塞其他事务读，但能快速判断是否允许加表锁。
事务隔离级别如何影响锁行为
隔离级别不是独立存在的“模式”，而是通过调整锁的持有范围和时间来实现的：
- READ UNCOMMITTED：几乎不加锁，脏读、不可重复读、幻读都可能发生。实际生产极少使用。
- READ COMMITTED：普通 SELECT 不加锁（快照读），UPDATE/DELETE 按 WHERE 条件加行锁，但不加间隙锁，所以可能遇到幻读；每次快照读都生成新版本视图。
- REPEATABLE READ（InnoDB 默认）：首次 SELECT 构建一致性视图（MVCC），后续读沿用该视图；范围 UPDATE/DELETE 会加临键锁，有效阻止幻读。
-
SERIALIZABLE：所有普通 SELECT 都隐式转为
SELECT ... LOCK IN SHARE MODE，强制加锁读，彻底串行化，性能代价最大。
MVCC：不靠锁也能“并发读”的秘密
MVCC（多版本并发控制）是 InnoDB 实现高并发读的关键，它让读操作基本不阻塞写，也不被写阻塞：
- 每行数据包含隐藏字段：
DB_TRX_ID（最后修改事务ID）、DB_ROLL_PTR（指向 undo log 中的历史版本）。 - 事务开启时获取一个唯一递增的 read view，其中记录了当前活跃事务 ID 列表及最小/最大事务 ID。
- 读取时根据 read view 判断哪些版本可见：仅对本事务可见、已提交且早于本事务启动的版本才可读。
- MVCC 主要服务于“快照读”（普通 SELECT），而“当前读”（如 SELECT ... FOR UPDATE、UPDATE、INSERT）仍需加锁确保最新状态。
死锁检测与避免：不只是“等超时”
InnoDB 采用等待图（wait-for graph）主动检测死锁，一旦发现立即回滚其中一个事务（通常选 undo log 最小的那个）：
- 常见死锁场景：两个事务以不同顺序更新同一组行（如事务 A 先更新 user 表再更新 order 表，事务 B 反过来）。
- 预防建议：固定 SQL 执行顺序（如按主键升序更新）、减少事务长度、避免在事务中用户交互等待、合理使用
SELECT ... FOR UPDATE替代先查后更。 - 监控手段：
SHOW ENGINE INNODB STATUS查看最近死锁详情；启用innodb_print_all_deadlocks将所有死锁写入错误日志。
