mysql没有运行时“切换锁级别”指令；行锁与表锁由不同机制触发，互斥而非可升级/降级——锁粒度取决于查询实际扫描范围，受索引是否生效、优化器决策等影响。
MySQL 本身没有“切换锁级别”的运行时指令——行锁和表锁不是同一把锁的两种模式，而是由不同机制、不同语句、不同上下文触发的互斥行为。你不能在事务中把一个 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 是锁一行、锁十行，还是锁全表，取决于它实际扫描了多少行——而这又取决于索引、统计信息、隔离级别和优化器决策。所有“看起来像切换”的现象，背后都是执行计划变化或锁作用域扩大所致。
