InnoDB不会主动将行锁升级为表锁；所谓“行锁变表锁”实为WHERE条件未走索引导致全表扫描、逐行加行锁（含间隙锁）的误判，真表锁仅来自LOCK TABLES、DDL或MyISAM引擎。
MySQL 不会自动把行锁升级为表锁——这是个常见误解。InnoDB 引擎本身没有“锁升级”机制，所谓“行锁变表锁”，通常是查询无法使用索引、扫描全表或隐式锁竞争扩大导致的锁范围失控，不是引擎主动升级，而是你写的 SQL 让它不得不锁更多。
为什么 UPDATE 或 DELETE 会锁整张表？
根本原因在于执行计划没走索引，InnoDB 只能对扫描到的每一行加锁；如果扫描了全表，就等于逻辑上“锁了所有行”，效果接近表锁。
- WHERE 条件列没索引，或用了函数/表达式（如
WHERE YEAR(create_time) = 2024） - 用了
OR连接多个非索引字段，导致索引失效 - 字符集或排序规则不一致，引发隐式类型转换（如
id是VARCHAR，但传入数字WHERE id = 123） - 使用了
LIKE '%abc'，索引无法有效利用
用 EXPLAIN 看执行计划：如果 type 是 ALL 或 index，且 rows 接近表总行数，那基本就是“伪表锁”现场。
SELECT ... FOR UPDATE 锁范围比预期大？
InnoDB 的行锁是基于索引实现的。如果你在非唯一索引或无索引字段上加锁，它可能锁住整个索引范围（gap lock + next-key lock），甚至因间隙重叠导致相邻事务被阻塞。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 在普通索引上做
WHERE status = 1，而status值重复度高 → 锁住大量索引项及间隙 - WHERE 条件落在索引最左前缀缺失时（如联合索引
(a,b,c)，只查WHERE b = 2）→ 索引失效，退化为扫描 - 事务中先
SELECT ... FOR UPDATE再UPDATE，但两次条件不一致 → 第一次锁的范围可能远超第二次实际修改的行
验证方式：SELECT * FROM performance_schema.data_locks; 查看当前事务持有的锁类型和对象。
如何避免“看起来像表锁”的阻塞？
核心思路是让每条 DML 都精准命中索引、最小化扫描、缩短事务生命周期。
- 所有
WHERE、JOIN、ORDER BY字段必须有合适索引，优先覆盖索引 - 避免在索引列上做计算或函数操作；改写为
WHERE create_time >= '2024-01-01' AND create_time - 批量更新分页处理：用主键 or 自增 ID 分段，例如
WHERE id BETWEEN 1000 AND 2000，别用LIMIT OFFSET做深分页 - 事务里不要混杂长耗时操作（如调外部 HTTP、生成报表），
UPDATE完立刻COMMIT - 读已提交（
READ COMMITTED）下 gap lock 会禁用，若业务允许，可考虑降隔离级别（但注意幻读风险）
真正难缠的不是锁本身，而是那些你以为只锁一行、其实锁了一片索引树的语句——它们不会报错，也不会警告，只在高并发时突然让整个表“卡住”。每次上线前跑一遍 EXPLAIN，比等压测时排查死锁更省力。
