MySQL锁机制是数据库用来协调多个事务并发访问同一资源的核心手段，核心目标是保障事务的隔离性与数据一致性。它不是靠用户手动控制全部流程，而是由存储引擎在执行SQL时自动加锁、事务结束时自动释放——但理解其原理，才能避开死锁、锁升级、性能瓶颈等常见问题。
锁的本质和作用
锁本质上是内存中的一种数据结构，记录着“谁（事务ID）、锁了什么（表/行/间隙）、以什么方式（S/X/IX/IS）”。它的直接作用有三个：
防止写冲突：比如两个事务同时修改同一行，排他锁（X锁）确保只有一个能成功 保障读一致性：在可重复读（RR）隔离级别下，通过行锁+间隙锁组合，避免幻读 协调多粒度操作：意向锁（IS/IX）让表锁和行锁能高效共存，不用逐行扫描判断冲突按粒度分：表锁、行锁、间隙锁
锁的粒度直接影响并发能力：
表锁：整张表被锁定，开销小、加锁快，但并发低。MyISAM只支持表锁；InnoDB在无索引条件查询或显式LOCK TABLES时也会退化为表锁 行锁：只锁索引记录本身（Record Lock），前提是SQL走索引。这是InnoDB默认行为，高并发OLTP场景的基石 间隙锁（Gap Lock）：锁住索引值之间的空隙，比如
WHERE id BETWEEN 10 AND 20会锁住(10,20)区间，防止其他事务插入新记录造成幻读。仅在可重复读隔离级别生效
按模式分：共享锁与排他锁
这是最基础的锁行为分类：
共享锁（S锁，读锁）：用SELECT ... LOCK IN SHARE MODE显式加。多个事务可共存，但阻止任何X锁。适合需要读取后校验、但不立即修改的场景 排他锁（X锁，写锁）：
UPDATE、
DELETE、
INSERT以及
SELECT ... FOR UPDATE自动加。一个X锁存在时，其他S/X锁全部阻塞。它是数据变更的强制保护屏障
InnoDB特有的协同锁：意向锁
当事务对某几行加了X锁，InnoDB会自动在表上加一个意向排他锁（IX）。这不是为了锁表，而是给其他想加表锁的事务“打个招呼”：
有IX锁 → 表明底下有行正被独占 → 其他事务申请表写锁会被拒绝 有IS锁 → 表明底下有行正被共享读 → 表读锁仍可加，但表写锁不行 这样就避免了每次加表锁都要遍历所有行检查锁状态，大幅提升效率
