mysql innodb无主动锁升级机制，所谓“行锁变表锁”实为索引失效导致全表扫描并逐行加锁，或rr级别下临键锁扩大范围所致；根本诱因包括where条件未走索引、函数/类型转换致索引失效、or连接非索引字段等。
锁升级不是MySQL的显式操作，而是隐式退化行为
MySQL（InnoDB）本身没有“锁升级”这个主动命令或配置项。所谓“锁升级”，实际是当查询无法使用索引时，UPDATE、DELETE 或 SELECT ... FOR UPDATE 等语句被迫对扫描范围内的所有行加锁，最终等效于锁住整张表——即行锁退化为表级效果。这不是优化器主动升级，而是因缺失索引导致的锁范围失控。
常见诱因包括：
-
WHERE条件字段未建索引（如UPDATE users SET status='x' WHERE age > 25，而age无索引） - 使用函数或表达式导致索引失效（如
WHERE YEAR(create_time) = 2025） - 隐式类型转换（如
id是INT，但传入字符串'123'） - 使用
OR连接多个非索引字段条件
这种“伪升级”会极大增加锁冲突概率，是死锁高频前置原因。
死锁的四个必要条件在InnoDB中都有对应实现
死锁不是随机发生的异常，而是满足四个经典条件后必然出现的状态。在 InnoDB 中，它们一一具象化为：
-
互斥条件：同一行上的
X锁与X锁/S锁互斥；间隙锁之间也互斥（尤其在 RR 隔离级别下） -
持有并等待：事务 A 已持
table_a.id=1的记录锁，同时请求table_b.id=2的锁；事务 B 反之 - 不可剥夺：InnoDB 不支持强行释放其他事务持有的锁，只能靠回滚打破循环
- 循环等待：InnoDB 的 wait-for graph 检测到 A→B→A 的环，立即触发死锁判定
注意：innodb_deadlock_detect=ON（默认开启）是检测循环等待的关键开关；关掉它，死锁不会被主动发现，只会卡在 innodb_lock_wait_timeout 后报超时错误，掩盖真实问题。
交叉更新顺序是最典型的死锁触发场景
两个事务以不同顺序访问相同资源集，是生产中最常见、最可复现的死锁来源。例如：
-- 事务1 BEGIN; UPDATE orders SET status = 'shipped' WHERE order_id = 1001; UPDATE users SET last_order_time = NOW() WHERE user_id = 5001; COMMIT;
-- 事务2 BEGIN; UPDATE users SET balance = balance - 100 WHERE user_id = 5001; UPDATE orders SET status = 'paid' WHERE order_id = 1001; COMMIT;
此时：
- 事务1 持有
orders行锁，等待users行锁 - 事务2 持有
users行锁，等待orders行锁 - InnoDB 检测到环形依赖，回滚其中一个事务（通常选 undo log 小的那个）
这类死锁与隔离级别无关，RC 和 RR 下都会发生；唯一可靠解法是**所有业务代码统一访问多表的顺序**（比如约定总是先 users 后 orders）。
间隙锁参与死锁常被忽略
在 RR 隔离级别下，WHERE 范围查询（如 id BETWEEN 10 AND 20）会触发 Gap Lock 或 Next-Key Lock，锁定索引间隙。这些锁不针对具体数据行，却能阻塞插入，也能卷入死锁。
示例：
BEGIN; SELECT * FROM products WHERE price > 99 AND price <p>若另一事务执行：</p><pre class="brush:php;toolbar:false;">INSERT INTO products (price) VALUES (120); -- 被阻塞
而它又恰好持有某行锁并等待第一个事务释放间隙锁，就构成死锁。这种死锁日志里不会显示“行号”，只写“gap lock on index …”，排查时容易漏掉。
真正棘手的是：即使你只更新单行，只要 SQL 带了范围条件（哪怕 id > 1000），就可能带上间隙锁——这和直觉不符，却是 RR 级别的设计使然。
