MySQL中锁与事务紧密耦合：事务隔离性依赖锁实现，锁的类型、粒度和持续时间由隔离级别和SQL语句决定；READ COMMITTED语句级加锁，REPEATABLE READ事务级加锁并引入间隙锁防幻读，SERIALIZABLE强制所有SELECT加共享锁。
MySQL 中的锁和事务是紧密耦合的机制：事务的隔离性依赖锁来实现，而锁的加持时机、粒度与持续时间又由事务的隔离级别和执行语句决定。
事务通过锁保障数据一致性
当开启一个事务（BEGIN 或 START TRANSACTION），后续的读写操作会根据隔离级别自动触发对应类型的锁：
- SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE 会显式加行级排他锁或共享锁；
- 普通 SELECT 在 READ COMMITTED 及以上级别中，不加锁但可能用 MVCC 快照读避免阻塞；
- UPDATE/DELETE/INSERT 语句在执行时会自动对涉及的索引记录加排他锁（X锁），确保修改期间不被并发覆盖。
不同隔离级别影响锁的行为
隔离级别不仅控制“能看到什么”，更直接改变锁的策略：
- READ UNCOMMITTED：基本不加锁（除极少数元数据锁），无事务保护，脏读风险高；
- READ COMMITTED：语句级加锁，每次 SELECT 读取最新已提交版本，非唯一条件更新可能引发间隙锁（仅在唯一索引匹配失败时）；
- REPEATABLE READ（InnoDB 默认）：事务级加锁，首次读建立快照，后续读复用；范围查询会加间隙锁（Gap Lock）或临键锁（Next-Key Lock），防止幻读；
- SERIALIZABLE：所有普通 SELECT 都隐式转为 SELECT ... LOCK IN SHARE MODE，强制加锁读，彻底串行化。
锁的类型与事务生命周期强绑定
锁不是独立存在的资源，它的申请、持有与释放完全由事务上下文管理：
- 锁在事务内第一条访问数据的语句执行时申请；
- 行锁、间隙锁、表锁等均随事务持续存在，直到 COMMIT 或 ROLLBACK 才释放；
- 若事务长时间未提交，它持有的锁会阻塞其他事务，容易引发锁等待甚至死锁；
- InnoDB 会为每个事务维护一个锁等待队列，并在检测到循环等待时主动回滚其中一个事务。
实际开发中需关注的关键点
理解锁与事务关系，能帮你避开常见并发陷阱：
- 避免长事务：减少锁持有时间，降低冲突概率；
- 按主键或唯一索引更新：可减少锁范围（只锁匹配行），避免全表扫描导致的锁升级；
- 注意隐式锁升级：如 WHERE 条件无索引，InnoDB 可能退化为表级意向锁 + 大量行锁；
- 合理选择隔离级别：多数业务用 REPEATABLE READ 足够，高并发统计类场景可降为 READ COMMITTED 提升并发度。
