许多开发者经常困惑：MySQL 的行锁和表锁之间究竟如何切换？实际上，并不存在所谓的“切换”机制。行锁与表锁并非同一把锁的不同等级，而是由完全不同的机制、SQL语句以及执行上下文触发的互斥行为。无法在事务中将 SELECT FOR UPDATE 获取的行锁“升级”为表锁，也无法将 LOCK TABLES t WRITE 持有的表锁“降级”为行锁。
更值得深入理解的问题是：哪些场景下，原本只锁定几行的操作，却意外演变为全表锁？以及如何有效避免这种陷阱？
为什么明明加了 WHERE 条件，却导致整张表被锁？
这并非锁的“切换”，而是查询优化器放弃了使用索引，导致 InnoDB 必须对扫描到的每一行逐一加锁，最终效果等同于全表锁。
- WHERE 条件字段未建立索引，或索引失效（常见情况：使用
LIKE '%abc'前缀模糊匹配、对索引列进行函数运算如col + 1 = 10、存在隐式类型转换）→ 触发全表扫描 → 每一行都被加锁 → 锁数量暴增，严重影响并发写入性能 - 即使存在索引，若优化器判断使用索引的成本更高（例如表数据量极小、索引区分度极差），它仍可能选择全表扫描 → 最终同样导致全表加锁
- 执行
EXPLAIN分析查询计划，重点关注type列：如果显示ALL或index，基本意味着正在对全表加锁
显式 LOCK TABLES 会直接接管行锁机制
一旦执行了 LOCK TABLES t WRITE，当前会话对该表的所有后续 DML 操作都将被阻塞，直到执行 UNLOCK TABLES。此时，即使在事务中执行 SELECT * FROM t WHERE id = 1 FOR UPDATE，也会报错：ERROR 1100 (HY000): Table 't' was not locked with LOCK TABLES。
LOCK TABLES属于会话级命令，不依赖于事务，且会隐式提交当前事务- 它与 InnoDB 的行锁机制完全隔离——这并非“升级”，而是“彻底接管”
- 混用
LOCK TABLES与事务内行锁属于高危操作，极易引发不可预测的阻塞或异常报错
如何确认当前 SQL 实际加的是行锁还是表锁？
不要依赖猜测，直接查询系统状态信息。
- 执行
SHOW ENGINE INNODB STATUS\G，重点关注 “TRANSACTIONS” 部分：若出现lock_mode X locks table表示表锁，出现lock_mode X locks rec but not gap则表示行锁 - 查询
INFORMATION_SCHEMA.INNODB_TRX：若TRX_ROWS_LOCKED值非常大（例如几万），而TRX_LOCK_STRUCTS为 0，很可能已退化为表级锁定逻辑 - 启用锁细节输出：执行
SET GLOBAL innodb_status_output_locks = ON，然后再次运行SHOW ENGINE INNODB STATUS，可获得更详细的锁信息
归根结底，真正的难点并非“如何切换”，而是理解一个核心原则：锁粒度由查询路径决定，而非由语句意图决定。一条 UPDATE 语句锁一行、锁十行，还是锁全表，完全取决于它实际扫描的行数——而这又由索引选择、统计信息、隔离级别以及优化器的决策共同决定。所有看似“切换”的现象，背后要么是执行计划发生了变化，要么是锁的作用域被意外扩大。
