InnoDB行锁仅在走有效索引时生效，否则退化为表锁；MyISAM始终使用表锁；SELECT...FOR UPDATE和LOCK IN SHARE MODE分别加X锁和S锁，均只锁实际扫描的索引记录。
MyISAM 默认用表锁，InnoDB 默认用行锁，但行锁可能“悄悄退化”成表锁
MySQL 的锁行为不是由 SQL 语句决定的，而是由存储引擎决定的。MyISAM 不支持行锁，所有读写操作都自动加表级锁；InnoDB 支持行锁，但**只在走索引时生效**——这是最常被忽略的前提。
常见错误现象：SELECT ... FOR UPDATE 执行后，整张表被卡住，其他事务连 INSERT 都等不到锁，明明只查了一行却像锁了全表。
- 检查执行计划：
EXPLAIN SELECT ... FOR UPDATE，如果type是ALL或index（没走有效索引），InnoDB 就会升级为表锁 - 没有
WHERE条件的UPDATE或DELETE必然触发表锁，哪怕表是 InnoDB 引擎 - 字符串字段用了
LIKE '%abc'、或对索引列做了函数操作（如WHERE YEAR(create_time) = 2025），索引失效 → 行锁失效
SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE 到底锁什么
这两个语句都是显式加锁，但锁的类型和范围完全不同，且只对 InnoDB 有效（MyISAM 下会被忽略或报错）。
使用场景：需要在读取后做判断再更新，又怕中间被别的事务改掉——比如扣库存前先查余额，就得防止别人同时扣。
-
LOCK IN SHARE MODE加的是共享锁（S 锁），允许其他事务继续加 S 锁，但阻塞 X 锁（即阻塞UPDATE/DELETE/FOR UPDATE） -
FOR UPDATE加的是排他锁（X 锁），其他事务无论想加 S 还是 X 锁都会被阻塞 - 二者都只锁住实际扫描到的索引记录（含主键/二级索引项），不是“查到的数据行”，更不是“结果集”——如果
WHERE条件命中多个索引项，就锁多个；如果没命中索引，就锁整张表
表锁不是“不用管”，LOCK TABLES 在某些运维场景下仍会误伤业务
虽然 MyISAM 自动加表锁、InnoDB 默认不走 LOCK TABLES，但有些 DBA 或备份脚本仍会手动执行它，而它对所有引擎都生效，且不遵循事务边界。
常见错误现象：执行 LOCK TABLES t1 WRITE 后，另一个连接执行 SELECT * FROM t1 卡住，但你查 SHOW PROCESSLIST 看不到明显阻塞源，因为锁不是事务级的。
-
LOCK TABLES会隐式提交当前事务（如果有），并释放之前所有行锁，这点极易被遗忘 - MyISAM 表一旦被
WRITE锁住，连SELECT都要排队；InnoDB 表虽能继续读（MVCC），但所有写操作（包括INSERT）都会等 - 忘记配对执行
UNLOCK TABLES？连接断开才会自动释放，期间整个表不可写
死锁不是“并发高才出”，InnoDB 行锁 + 无序加锁顺序就能触发
表锁不会死锁（串行化），但行锁会——而且不需要高并发，两个事务以不同顺序访问两行数据就足够了。
典型例子：事务 A 先 SELECT ... FOR UPDATE 锁住 id=1，再锁 id=2；事务 B 反过来先锁 id=2 再锁 id=1。只要执行时机交错，MySQL 就检测到循环等待并回滚其中一个。
- 死锁日志里会出现
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和*** (2) HOLDS THE LOCK(S):，关键看“谁在等谁、谁拿着什么” - 避免方式不是减少锁，而是统一加锁顺序：比如总是按
id ASC排序后再批量FOR UPDATE - 不要在应用层 sleep 后再更新——锁持有时间越长，死锁概率越高；也别在事务里调外部 HTTP 接口
真正麻烦的不是锁本身，而是你以为加了行锁，其实 MySQL 悄悄换成了表锁；或者你以为锁住了“数据行”，其实锁的是“索引项”，而那个索引项还可能覆盖多行（比如唯一索引冲突时的插入意向锁）。这些细节不看执行计划、不查 INFORMATION_SCHEMA.INNODB_TRX，光靠肉眼 SQL 几乎没法验证。
