InnoDB没有真正的锁升级机制，所谓“锁升级”实为WHERE条件未走索引导致全表扫描，进而逐行加锁，锁行数等于扫描行数。
MySQL InnoDB 本身没有自动锁升级机制，所谓“锁升级”其实是行锁失效、范围失控或隐式表级阻塞的表现，不是功能，而是问题信号。
为什么 UPDATE/DELETE 会锁整张表
根本原因不是“引擎主动升级”，而是 WHERE 条件没走索引，导致全表扫描。InnoDB 必须逐行判断是否匹配，过程中会对所有扫描过的记录（甚至页）加锁——哪怕最终只改 1 行，也可能锁住几万行。
- 常见诱因：
name字段无索引，却执行UPDATE users SET status=1 WHERE name='Alice' - 索引失效写法：
WHERE YEAR(create_time) = 2025（函数导致索引无法使用） - 模糊查询滥用：
WHERE phone LIKE '%138%'，无法命中索引前缀 - 类型隐式转换：
WHERE user_id = '123'（user_id是INT，字符串触发全表扫描）
怎么确认是不是锁范围失控了
不能靠猜，得看三项关键指标：
- 查
information_schema.INNODB_TRX：如果TRX_ROWS_LOCKED值远超业务预期（比如显示 50000，但你只改 1 行），基本就是锁失控 - 运行
SHOW ENGINE INNODB STATUS\G：关注输出中heap size，若超过 1MB，说明锁结构内存占用过大，InnoDB 已倾向简化处理 - 执行
SHOW GLOBAL STATUS LIKE 'table_locks%'：若table_locks_waited明显上升，而table_locks_immediate下降，说明有非 MyISAM 引擎的语句正在遭遇表级阻塞效应
真正有效的规避手段
核心思路是让每条 DML 都能精准定位到目标行，而不是“扫完再筛”：
- 强制走索引：用
EXPLAIN确认执行计划，避免type为ALL或index - 删/改大表必须分批：例如
DELETE FROM log WHERE ts 改成每次删 1000 行，配合 <code>WHERE id BETWEEN ? AND ? - 避免在事务里混用 DDL：如
ALTER TABLE和UPDATE同处一个事务，会触发隐式表级协调逻辑 - RR 隔离级别下慎用大范围
SELECT ... FOR UPDATE：WHERE amount BETWEEN 100 AND 1000可能生成大量间隙锁，堆满内存后行为不可控
最常被忽略的一点：锁问题往往不发生在高并发瞬间，而藏在低频但低效的定时任务里——比如凌晨跑的清理脚本没加索引，悄无声息地把白天的交易接口拖垮。排查时别只盯高峰期 SQL，得翻 slow_log 里执行时间长、扫描行数多的冷门语句。
