InnoDB从不主动将行锁升级为表锁；所谓“升级”实为WHERE条件未走索引导致全表扫描、逐行加行锁（含间隙锁）的误判，真表锁仅来自LOCK TABLES、DDL或MyISAM引擎。
InnoDB 从不主动把行锁升级为表锁——你不需要、也不该“升级”行锁来执行批量维护。所谓“升级”是误判，真实需求是：在可控范围内安全执行大范围 DML。真表锁只来自 LOCK TABLES、ALTER TABLE 或 MyISAM，而它们会彻底阻塞并发写入，不适合常规维护。
为什么不能靠“锁升级”做批量维护？
MySQL 8.0+ 的 InnoDB 没有自动锁升级机制。当你看到 UPDATE ... WHERE status = 0 卡住或阻塞其他事务，大概率是因为：
- WHERE 条件没走索引 → 全表扫描 → 对每行加
RECORD锁（含间隙锁）→ 锁了 5 万行，等效于表锁 - 事务太大、时间太长 → 持锁期间其他 DML 被阻塞，看起来像“锁表”
- 执行
SHOW ENGINE INNODB STATUS\G看到 “HOLDS THE LOCK(S)” 并不表示真表锁，它只显示最近活跃事务的锁，漏掉静默持有者
如何确认当前是不是真表锁？
查 performance_schema.data_locks，这是 MySQL 8.0+ 唯一可靠方式：
SELECT LOCK_TYPE, LOCK_MODE, INDEX_NAME FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table';
如果 LOCK_TYPE = 'TABLE'，才是真表锁（比如你手动执行过 LOCK TABLES t WRITE 或正在跑 ALTER TABLE）；只要 LOCK_TYPE = 'RECORD'，哪怕锁了 10 万行，也只是行锁膨胀，不是“升级”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
批量维护的正确做法：绕过锁膨胀，而不是制造表锁
目标不是让锁变“粗”，而是让每次加锁尽可能少、时间尽可能短：
- 先用
EXPLAIN确认语句是否走索引：type不能是ALL，key不能是NULL - 避免隐式转换：
WHERE phone = 138（phone 是VARCHAR）会导致索引失效 - 批量删除/更新必须带
LIMIT，例如：DELETE FROM log WHERE ts - 循环执行，每次提交事务，释放锁；不要在一个事务里删 5 万行
- 如果 WHERE 条件天然无法走索引（如
LIKE '%abc%'），改用FULLTEXT或导出到 Elasticsearch 处理
真正需要表锁的场景极少，比如做原子性结构变更或全表归档。但那不是“升级行锁”，而是明确选择牺牲并发换一致性——这和日常批量维护的目标背道而驰。最容易被忽略的一点是：你以为在“优化锁”，其实是在对抗优化器；真正该调的从来不是锁粒度，而是执行计划本身。
