MySQL锁是分层多维的并发控制机制，按粒度分表锁、行锁、间隙锁，按行为分S/X/IS/IX锁，按逻辑分悲观与乐观锁，MVCC提供快照读；常见问题源于隔离级别、索引缺失或事务使用不当。

MySQL锁不是一种锁，而是一套分层、多维、按需启用的并发控制机制；实际开发中你遇到的“卡住”“死锁”“查不到最新数据”，几乎都和它有关。

按粒度分：表锁、行锁、间隙锁，别乱用

粒度决定并发能力——越细越快，但也越难管。

• 表锁（LOCK TABLES t1 READ/WRITE）：整张表被锁死，其他事务连 SELECT 都可能被阻塞（尤其 WRITE 锁）。MyISAM 默认用它；InnoDB 仅在没走索引、全表扫描或显式调用时才退化为表锁。
• 行锁（InnoDB 默认）：只锁命中索引的那几行。但注意：没索引 = 没行锁，InnoDB 会直接升级为表锁。
• Gap Lock 和 Next-Key Lock：只在 REPEATABLE-READ 隔离级别生效，用于防止幻读。比如 WHERE id BETWEEN 10 AND 20，会锁住 (10,20) 这个间隙，甚至 (10,20]（含20行）。READ-COMMITTED 下这些锁不生效，行锁退化为纯 Record Lock。

按行为分：S锁、X锁、IS/IX锁，必须懂意向锁的作用

你写 SELECT ... FOR UPDATE 加的是 X 锁，但 InnoDB 实际上先申请 IX 表级意向锁——这是为了快速判断“这张表有没有人正在改行”，避免每次加行锁都扫全表。

• S锁（共享锁）：SELECT ... LOCK IN SHARE MODE 加的，允许多个事务同时读，但谁都无法加 X 锁。
• X锁（排他锁）：UPDATE、DELETE、SELECT ... FOR UPDATE 默认加的，互斥一切其他锁。
• IS/IX锁 是“预告”：事务还没锁行，但声明“我马上要锁几行读/写”，让表级操作（如 DROP TABLE）能立刻感知冲突并拒绝，而不是等到最后才发现。

按实现逻辑分：悲观锁 vs 乐观锁，别拿 version 字段硬套 InnoDB

InnoDB 的行锁是典型的悲观锁实现；而所谓“乐观锁”，MySQL 本身不提供原生命令，version 字段方案是你自己在应用层写的逻辑，数据库只负责执行 UPDATE ... WHERE version = ? 并返回影响行数。

• 真用悲观锁？确保 SQL 走索引、事务尽量短、避免 SELECT ... FOR UPDATE 后长时间不提交。
• 想用乐观锁？别依赖 MySQL 自动处理，UPDATE 必须带 WHERE version = xxx，且检查 affected_rows == 1，否则就是更新丢失。
• MVCC 不是乐观锁，它是快照读机制：普通 SELECT 不加锁，靠隐藏字段 DB_TRX_ID 和 DB_ROLL_PTR 回溯版本——这正是为什么你 UPDATE 未提交时，别人 SELECT 还能看见旧值。

实战中最容易踩的三个坑

很多“锁表现异常”，其实不是锁错了，而是没看清隔离级别、索引状态或事务边界。

• 在 READ-COMMITTED 下还指望 Gap Lock 防幻读？不行。它只在 REPEATABLE-READ 生效。
• 执行 UPDATE t SET x=1 WHERE y=999 卡住？先 EXPLAIN 看是否走了索引；没走，就等于锁了全表。
• 用 FOR UPDATE 却发现没锁住？确认语句是否在事务内（BEGIN / START TRANSACTION），且事务没提前 COMMIT 或 ROLLBACK。

锁不是配置项，是执行路径的副产品；真正要盯的，永远是那条 SQL 走不走索引、跑在什么隔离级别、包没包在事务里。