根本原因是innodb未走索引时被迫全表扫描并逐行加锁，效果等同表锁；where条件无索引、隐式类型转换或字符集不匹配均会导致该问题，explain显示type=all或key=null即为明确信号。
UPDATE 在并发下“看起来”升级为表锁，根本原因不是锁机制主动升级，而是 InnoDB 没有真正意义上的行锁升级逻辑——它只是在无法走索引时，被迫对所有扫描过的行逐个加锁，范围覆盖全表，效果等同于表锁。
WHERE 条件没走索引 → 全表扫描 + 逐行加锁 = 等效表锁
这是最常见、最隐蔽的“伪升级”。InnoDB 不会把 5000 个行锁合并成一个表锁，但它会在全表扫描路径上，给每一条扫描到的记录加 Record Lock，再配合 Gap Lock 封闭区间，最终锁住整个主键索引范围。
-
EXPLAIN显示type=ALL或key=NULL就是明确信号 - 即使只匹配 1 行（比如
UPDATE users SET status=1 WHERE name='alice'），只要name没索引，仍会遍历所有聚簇索引页 - 并发事务执行任意
UPDATE或SELECT ... FOR UPDATE，只要涉及同一张表，大概率被阻塞——因为锁已遍布全表
隐式类型转换让索引失效，触发全表扫描
字段类型和查询值类型不一致时，MySQL 会做隐式转换，导致索引无法命中。这不是语法错误，但锁范围爆炸式扩大。
-
user_id是INT，却写WHERE user_id = '123'→ 字符串转整数，索引失效 -
phone是VARCHAR(20)，却写WHERE phone = 13800138000→ 数字转字符串，也可能失效（取决于 collation） - 字符集不匹配：比如列用
utf8mb4，而连接参数或常量用utf8，比较时无法使用索引
大范围更新未分批，锁数量多且持续时间长
单条 UPDATE 影响几万行，即使有索引，也会导致大量行锁长期持有，增加死锁概率，并让其他事务长时间等待——监控里看到的 “TABLE LOCK” 往往是等待链末端的误判，实际仍是行锁堆积。
- 避免
DELETE FROM logs WHERE created_at 这类语句直接执行 - 改用分批：加
LIMIT 1000，循环执行，每次提交后释放锁 - 注意：
ORDER BY+LIMIT组合可能因排序开销放大锁持有时间，优先按主键范围切片（如id BETWEEN ? AND ?）
DDL 操作或显式 LOCK TABLES 才是真表锁
这类操作不经过 InnoDB 的行锁系统，直接由 Server 层加表级锁，与“升级”无关，但效果更彻底、更易识别。
-
ALTER TABLE、TRUNCATE TABLE、OPTIMIZE TABLE都会触发元数据锁（MDL），阻塞所有 DML -
LOCK TABLES users WRITE是手动表锁，UNLOCK TABLES才释放，且会隐式提交当前事务 - 外键级联删除（
ON DELETE CASCADE）若子表无索引，父表删除一行可能触发子表全扫+全锁
真正麻烦的从来不是“锁升级”，而是你没意识到那条 UPDATE 其实根本没走索引——它已经在后台锁了 8000 行，而你只盯着执行计划里那行 rows=1。
