SQL锁机制是保障数据一致性的核心，但易引发死锁；需理解锁类型（行锁、间隙锁、临键锁）、加锁时机及竞争路径：行锁作用于索引键，间隙锁防幻读，临键锁为前两者组合。
SQL数据库的锁机制是保障数据一致性和并发安全的核心，但不当使用容易引发死锁，导致事务长时间阻塞甚至应用超时。关键在于理解锁的类型、加锁时机和资源竞争路径，而非单纯依赖数据库自动检测。
锁的类型与触发场景
不同隔离级别和SQL语句会隐式申请不同粒度的锁：
- 行锁（Record Lock）：UPDATE、DELETE 或带 WHERE 条件的 SELECT … FOR UPDATE 在索引键上加锁；若 WHERE 不走索引，可能升级为表锁
- 间隙锁（Gap Lock）：在可重复读（RR）隔离级别下，防止幻读，锁定索引区间（如 id > 10 AND id
- 临键锁（Next-Key Lock）：行锁 + 间隙锁的组合，InnoDB 默认使用，覆盖记录本身及前一个间隙
- 意向锁（Intention Lock）：表级元数据锁，表明事务将在某行加锁，不阻塞读，但会阻塞其他事务对整表的 DDL 操作
死锁如何发生
死锁本质是多个事务循环等待彼此持有的锁资源。典型模式是两个事务以不同顺序访问相同资源：
- 事务 A 先更新用户表 id=100，再更新订单表 order_no='O001'
- 事务 B 先更新订单表 order_no='O001'，再更新用户表 id=100
- 若两者执行时间交错，A 持有用户锁等待订单锁，B 持有订单锁等待用户锁，形成闭环
InnoDB 会主动检测死锁（通过 wait-for graph），选择回滚 undo log 量小的事务作为牺牲者，并抛出 Deadlock found when trying to get lock 错误。
定位与分析死锁日志
开启 innodb_print_all_deadlocks = ON 后，MySQL 将把完整死锁信息写入错误日志。重点关注：
- TRANSACTION 块：查看每个事务的 ID、隔离级别、运行时间、持有锁和等待锁的详细对象（如 table、index、lock_mode、lock_trx_id）
- WEIGHT：标识哪个事务被选为 victim
- *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 明确当前卡在哪一行/哪个索引上
- *** (2) HOLDS THE LOCK(S): 对照看对方持有哪些锁，交叉比对即可还原冲突路径
实用解决与规避策略
死锁无法完全杜绝，但可通过设计降低概率：
- 固定访问顺序：所有业务逻辑按统一字段排序后批量操作（如先按 user_id 升序更新，再按 order_id 升序处理）
- 减少事务粒度：避免在事务中调用远程服务或执行耗时计算；将大事务拆成多个小事务
- 合理建索引：确保 WHERE / JOIN / ORDER BY 字段都有高效索引，避免全表扫描导致锁升级
- 谨慎使用 SELECT … FOR UPDATE：仅在真正需要强一致性写场景下加锁；考虑用乐观锁（version 字段）替代部分悲观锁
- 应用层重试机制：捕获 Deadlock 异常后延迟 10–100ms 再重试，避免雪崩式重试冲击
