MySQL事务与锁紧密配合：事务定义操作，锁保障隔离性；锁依附于事务生命周期，不同隔离级别对应不同锁策略与MVCC组合，死锁源于多事务循环等待对方持有的锁。
MySQL事务和锁是紧密配合的一对机制：事务定义“要做什么”，锁决定“别人能不能同时做”。没有锁，事务的隔离性就无法保障；没有事务，锁就失去上下文约束——比如行锁只在事务中生效，事务提交或回滚后锁自动释放。
事务的隔离性靠锁来实现
事务四大特性（ACID）中的隔离性，直接依赖锁机制落地。不同隔离级别背后，实际是锁策略与MVCC（多版本并发控制）的组合：
- READ UNCOMMITTED：基本不加读锁，允许脏读
- READ COMMITTED：每次SELECT都用快照读，写操作加行级X锁，但锁在语句结束即释放
- REPEATABLE READ（InnoDB默认）：首次读生成一致性视图，后续读复用该视图；写操作加行级X锁，且锁持续到事务结束——这能防止不可重复读，也配合间隙锁（Gap Lock）抑制幻读
- SERIALIZABLE：所有SELECT隐式加上共享锁（S锁），强制串行执行
锁的生命周期由事务管理
锁不是独立存在的，它依附于事务：
- 显式事务中（START TRANSACTION），加锁（如SELECT … FOR UPDATE）后，锁会一直持有，直到COMMIT或ROLLBACK
- 自动提交模式下（autocommit=1），每条DML语句自成一个事务，对应锁也仅存活于该语句执行期间
- 意向锁（IS/IX）在事务开始访问表时自动申请，属于表级元信息锁，为行锁做铺垫，同样随事务结束而释放
常见锁行为与事务操作直接对应
哪些SQL会触发什么锁，取决于事务状态和语句类型：
- SELECT … LOCK IN SHARE MODE → 加行级S锁（其他事务可读不可写）
- SELECT … FOR UPDATE → 加行级X锁（其他事务不可读不可写）
- UPDATE/DELETE WHERE 条件命中索引 → 对匹配行加X锁（InnoDB默认行为）
- INSERT → 涉及自增主键时会短暂持有AUTO-INC表锁；插入过程中还会加插入意向锁（Insert Intention Lock），用于协调间隙锁
死锁和锁等待本质是事务资源竞争
两个事务互相持有对方需要的锁，并等待对方释放，就会形成死锁。MySQL能自动检测并回滚其中一个事务（通常选代价小的那个）。这类问题只在多语句事务中高频出现：
- 事务A先更新id=1，再更新id=2
- 事务B先更新id=2，再更新id=1
- 若执行时机交错，就可能锁住彼此，触发死锁