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 走不走索引、跑在什么隔离级别、包没包在事务里。
