InnoDB行锁不会主动升级为表锁，但在无索引、索引失效或全表扫描等场景下会退化为锁定整个聚簇索引，效果等同于表锁；这是资源权衡下的被动兜底行为，非MyISAM式原生表锁。
行锁失效时InnoDB会悄悄升级成表锁
InnoDB本身不提供显式的“表锁”指令，但当SQL无法走索引、或扫描范围过大（比如 WHERE name LIKE '%abc%'），它会放弃行锁，退化为锁定整个聚簇索引——效果等同于表锁。这不是MyISAM那种原生表锁，而是InnoDB在资源权衡下的兜底行为。
常见触发场景包括：
-
UPDATE users SET status=1 WHERE city='Shanghai'，而city字段没建索引 - 使用
OR连接多个非索引条件，导致优化器放弃索引合并 - 全表扫描的
SELECT ... FOR UPDATE（尤其在WHERE条件为空或恒真时） - 对大字段（如
TEXT）做前缀索引但查询未命中前缀长度
MyISAM表锁是强制且不可降级的
MyISAM没有事务、没有MVCC、也没有行粒度控制能力。它的写操作（INSERT/UPDATE/DELETE）默认加的是整表写锁，读操作加的是整表读锁。哪怕你只更新一行，其他会话对这张表的任何写操作都会被阻塞，连 INSERT 到末尾都不行（除非启用 concurrent_insert 且满足尾部插入条件）。
关键区别在于：MyISAM的表锁是设计使然，InnoDB的“表锁”是异常退化。前者稳定可预期，后者隐蔽难排查。
验证锁类型最直接的方法是查 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCKS
在事务执行中，运行以下语句能快速定位锁粒度：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT trx_id, trx_state, trx_started, trx_query FROM INFORMATION_SCHEMA.INNODB_TRX;
如果 trx_query 显示的是类似 UPDATE t1 SET x=1 WHERE y=5，但对应事务长时间卡住且影响全表写入，大概率已升级为表级锁；而 MyISAM 根本不会出现在这个视图里——它压根不进 INNODB_TRX。
补充验证手段：
- 用
SHOW OPEN TABLES WHERE In_use > 0查 MyISAM 表是否被锁住 - 对 InnoDB 表执行
SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME = 'innodb_row_lock_time_avg';，数值突增可能暗示锁冲突加剧，但无法区分是行锁争用还是锁升级 - 开启
innodb_status_output_locks后查SHOW ENGINE INNODB STATUS，其中TRANSACTIONS部分会明确写出“TABLE LOCK”或“RECORD LOCK”
引擎混用时锁行为不会互相影响，但业务逻辑容易误判
一个库中同时存在 InnoDB 表和 MyISAM 表，它们的锁机制完全隔离。InnoDB 的行锁不会让 MyISAM 表变慢，反之亦然。真正出问题的地方在于开发人员的直觉误判：比如以为“我用了InnoDB就一定不会锁表”，结果上线后某条没走索引的 UPDATE 把整张用户表卡住，而监控只盯着 Threads_running，没看锁状态。
最容易被忽略的一点是：MySQL 的 LOCK TABLES 命令对两种引擎都生效，且是显式表锁——它会绕过所有引擎自身的锁机制，直接在server层加锁。如果你在代码里写了 LOCK TABLES user WRITE，那不管 user 是什么引擎，它都变成事实上的串行访问。
