事务和锁协同保障MySQL并发安全：事务定义操作逻辑，锁实现隔离性；四种隔离级别通过不同加锁策略达成，行锁、间隙锁等分层协作确保数据一致性与高并发性能。
事务和锁是 MySQL 并发控制的两个核心支柱，它们紧密配合：事务定义“要做什么”，锁决定“怎么做才能安全地做”。没有锁，事务的隔离性（ACID 中的 I）就无法保障；没有事务，锁就失去了上下文约束，容易变成无意义的资源阻塞。
事务的隔离性靠锁来实现
MySQL 的四种隔离级别（读未提交、读已提交、可重复读、串行化）本质上是通过不同强度的加锁策略达成的：
- 读未提交：几乎不加锁，允许脏读，性能最高但一致性最弱
- 读已提交：普通 SELECT 不加锁（依赖 MVCC），但 UPDATE/DELETE 会对涉及行加排他锁（X 锁）
- 可重复读（InnoDB 默认）：SELECT 使用 MVCC 快照读，避免阻塞；但 FOR UPDATE 或 LOCK IN SHARE MODE 会加行级 S/X 锁，并配合间隙锁（Gap Lock）防止幻读
- 串行化：所有 SELECT 都隐式转为 SELECT ... LOCK IN SHARE MODE，强制加共享锁，彻底串行执行
锁是事务执行时的实时保护机制
当事务执行 DML 操作（如 UPDATE、DELETE、INSERT）或显式加锁语句时，InnoDB 会按需生成锁结构并绑定到具体记录或索引上：
- 事务 T1 修改某行前，先尝试获取该行的 X 锁；若成功，其他事务对该行的 X/S 锁请求都会被挂入等待队列
- 事务 T2 同时想改同一行，发现已被 T1 持有 X 锁，就会创建自己的锁结构，is_waiting = true，进入阻塞状态
- T1 提交后释放锁，InnoDB 唤醒队列头部的 T2，将其 is_waiting 设为 false，T2 继续执行
- 锁不是静态分配的，而是动态创建、按 FIFO 管理的队列结构，只存在于有加锁意图的事务中
不同锁类型服务于不同事务场景
MySQL 的锁不是单一工具，而是一套分层协作机制：
- 行锁（Record Lock）：锁定索引项本身，用于精确更新，是高并发写操作的基础
- 间隙锁（Gap Lock）：锁定索引区间（如 id > 10 AND id
- 临键锁（Next-Key Lock）：行锁 + 间隙锁的组合，InnoDB 在可重复读下默认使用，覆盖“当前记录及之前间隙”
- 意向锁（IX/IS）：表级轻量标记，表明事务将在某行加 X/S 锁，避免检查全表行锁时的性能开销
- 元数据锁（MDL）：保护表结构变更（如 ALTER TABLE），确保 DML 与 DDL 不冲突
事务生命周期决定锁的持有时间
锁不是永久存在的，它的生命周期严格受事务控制：
- 锁在事务第一次访问某行时申请，不是在 BEGIN 时就全部加好
- 行锁在事务 COMMIT 或 ROLLBACK 后立即释放；表锁（如 AUTO_INC 锁）在 INSERT 完成后即释放
- 长事务 = 长持锁 = 更高锁冲突概率，这也是为什么线上要避免超时未提交的事务
- 死锁检测由 InnoDB 自动触发，选中一个事务回滚（通常是 undo log 最小的那个），释放其所有锁，让其他事务继续
