innodb行锁不会升级为表锁，但无索引时全表扫描会逐行加x锁及间隙锁，锁行数接近全表且覆盖所有插入间隙，逻辑上等效表锁。
全量更新没走索引，InnoDB 会退化成表级锁
MySQL 的 InnoDB 引擎本身不支持真正的“表锁”，但当 UPDATE 或 DELETE 语句无法使用索引定位行时，它会扫描全表——每扫一行就加一个行锁（X 锁），最终效果等价于锁住整张表。这不是设计缺陷，而是实现机制：没有索引 → 无法快速定位 → 必须逐行判断 → 行锁数量爆炸 → 锁管理开销剧增，触发锁升级感知（虽无显式升级指令，但行为上已接近表锁）。
常见触发场景包括：
-
UPDATE users SET status = 1;（无WHERE条件） -
UPDATE orders SET paid = 1 WHERE user_id = 123;，但user_id列没有索引 UPDATE logs SET archived = 1 WHERE created_at ，而 <code>created_at无索引或索引选择性差
多个全量更新并发执行，极易形成交叉等待死锁
假设事务 A 和事务 B 同时执行无索引的 UPDATE t SET x = 1;，InnoDB 按聚簇索引物理顺序逐行加锁。但实际加锁顺序受 MVCC 版本、缓冲池状态、甚至行迁移影响，并不严格一致。可能出现：
- 事务 A 先锁住第 100 行，再锁第 200 行
- 事务 B 先锁住第 200 行，再锁第 100 行
- 两者卡在“互相等待对方释放下一行”的状态，InnoDB 检测到后回滚其中一个，报错：
Deadlock found when trying to get lock; try restarting transaction
这种死锁不是因为业务逻辑冲突，纯粹是底层加锁顺序不可控导致的——尤其在 RR 隔离级别下，还可能叠加 Gap Lock，让范围更难预测。
为什么加了索引也未必安全？注意隐式类型转换
即使字段有索引，以下写法仍会导致全表扫描和锁扩大：
-
UPDATE users SET name = 'a' WHERE mobile = 13800138000;，但mobile是VARCHAR类型，数字比较会触发隐式转换，索引失效 -
UPDATE logs SET processed = 1 WHERE DATE(created_at) = '2026-09-01';，函数操作使索引无法下推 -
UPDATE t SET v = 1 WHERE id IN (SELECT id FROM t2 WHERE ...);，子查询未优化，外层可能退化为全表匹配
这类语句在 EXPLAIN 中会显示 type: ALL 或 key: NULL，就是危险信号。
真正安全的全量更新策略只有两种
想避免锁升级和死锁，不能靠“运气”或“降低并发”，得从执行路径上切断风险：
- **分批 + 主键范围 + 显式索引提示**：
UPDATE t SET status = 1 WHERE id BETWEEN 1000 AND 2000 AND status != 1;，确保id是主键或有覆盖索引 - **用低隔离级别临时绕过间隙锁**：在非关键批量任务中，可设
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;，关闭 Gap Lock，但需确认业务能接受幻读 - **绝对不要在高峰期执行无 WHERE 的 UPDATE/DELETE**：哪怕加了索引，也可能因统计信息陈旧导致执行计划突变，锁住意外多的行
最常被忽略的一点：SHOW ENGINE INNODB STATUS 输出里的 lock_mode X locks rec but not gap 看似安全，但如果前面有几十万行被锁，后面事务依然会被阻塞——锁数量本身就会拖慢整个引擎调度。
