不会自动升级，但会退化为更粗粒度的锁——本质是innodb在无法精确定位行时放弃行锁，转而锁住整个索引范围甚至整张表；关键触发条件是查询未命中索引，如where age=25 for update中age无索引，则全表扫描并加锁，效果接近表锁。
行级锁失效时会自动升级为表级锁吗？
不会自动升级，但会「退化为更粗粒度的锁」——本质是 InnoDB 在无法精确定位行时，放弃行锁，转而锁住整个索引范围甚至整张表。关键触发条件是：查询未命中索引。
比如 SELECT * FROM users WHERE age = 25 FOR UPDATE，若 age 字段无索引，InnoDB 只能全表扫描，此时会为所有扫描过的记录加锁；在可重复读隔离级别下，还可能对间隙加锁，最终效果接近表锁，且阻塞严重。
- 必须确保
WHERE条件字段有可用索引（主键、唯一索引、普通索引均可） - 避免在索引字段上做函数操作，如
WHERE YEAR(create_time) = 2024会让索引失效 - 注意隐式类型转换，比如用字符串查数字主键：
WHERE id = '1'可能导致索引不走 - 可通过
EXPLAIN确认是否走了索引，再结合SELECT * FROM information_schema.INNODB_TRX观察实际锁范围
什么时候该主动用 LOCK TABLES 而不是事务内行锁？
仅在明确需要「阻断所有并发访问」且操作时间极短时才考虑 LOCK TABLES，例如 DDL 变更前的瞬时保护、冷备前的只读快照准备。
它和事务内行锁根本不在同一层级：前者是会话级显式锁，一执行就隐式提交当前事务；后者是事务内隐式/显式加的行级资源锁，受事务生命周期控制。
-
LOCK TABLES t1 WRITE会立即释放当前事务持有的所有行锁，并阻止其他会话读写t1 - MyISAM 表只能用
LOCK TABLES，InnoDB 表尽量避免——混用极易引发锁等待或死锁 - DDL 操作（如
ALTER TABLE）本身就会触发元数据锁（MDL），无需额外LOCK TABLES - 真正需要「全局一致性备份」时，优先用
FLUSH TABLES WITH READ LOCK（全局锁），而非单表锁
如何判断当前事务用的是行锁还是表锁？
不能靠 SQL 写法猜测，得看执行时的锁行为。核心观察点有两个：是否走索引 + 是否扫描了非目标行。
最直接的方法是查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS，再关联 INNODB_LOCKS（MySQL 8.0+ 已弃用该表，改用 performance_schema.data_locks）。
- 执行
SELECT * FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table' - 关注
LOCK_MODE字段：X,REC_NOT_GAP是标准行排他锁，TABLE或IX（意向锁）+ 大量REC_NOT_GAP可能意味着锁范围过大 - 若发现
LOCK_DATA显示多行值，或出现gap before rec，说明已涉及间隙锁，虽仍是行级锁范畴，但已扩大保护边界 - 长时间未释放的锁，优先检查是否有未
COMMIT或ROLLBACK的事务
切换锁粒度的本质不是语法选择，而是访问路径设计
所谓「合理切换」，其实是个伪命题——InnoDB 不提供手动切换指令，一切由查询计划决定。你真正能控制的，只有索引结构和 WHERE 条件的精确性。
业务层想「降级」到表锁？说明当前行锁已因热点行争抢成为瓶颈，这时该做的不是换锁，而是拆分热点（如分库分表、引入缓存、变更主键设计）；想「升级」到行锁？先确认是不是漏建索引或写了模糊查询。
最容易被忽略的一点：即使用了 FOR UPDATE，如果事务里后续语句没走索引，前面加的行锁也救不了整体性能——锁只是并发控制手段，不是性能银弹。
