mysql行锁不会升级为表锁，真实情况是：无索引时全表扫描并逐行加record lock或next-key lock，锁大量行导致效果等同表锁，但底层仍是行级锁。
MySQL 行级锁不会“自动升级”为表锁——InnoDB 根本没有锁升级机制。所谓“升级”，其实是 WHERE 条件没走索引时，InnoDB 被迫全表扫描并逐行加 X 锁，效果等同于锁表。
为什么没走索引就等于锁全表
InnoDB 的行锁是加在索引记录上的，不是加在数据行上。当 WHERE 条件无法命中任何索引（比如字段无索引、隐式类型转换、函数包裹、字符集不匹配），优化器只能选全表扫描：从聚簇索引最左叶节点开始，挨个读取每条主键记录，并对每条扫描到的记录加 X 锁（或 Next-Key Lock）。哪怕只改 1 行，只要没索引，它就得扫完全部主键页。
- 执行
UPDATE users SET status=1 WHERE name='alice'，但name没索引 → 扫描所有主键行，每行加锁 -
EXPLAIN显示type=ALL或key=NULL，就是明确信号 - RR 隔离级别下还会额外加 Gap Lock，把扫描路径上的间隙也锁住，进一步扩大阻塞范围
哪些写法会让索引“看起来走了”，实则失效
EXPLAIN 显示用了索引，不代表加锁安全。真正决定锁粒度的是执行时能否精确定位物理行。
-
WHERE user_id = '123'：字段是INT，传字符串触发隐式转换，索引失效 -
WHERE UPPER(name) = 'ALICE'：函数包裹索引列，无法做索引查找 -
WHERE created_at > '2026-01-01'，但联合索引是(status, created_at)→ 不满足最左前缀，该索引基本不用 - 连接参数用
utf8，而列是utf8mb4→ 字符集不匹配，比较时跳过索引
怎么验证 UPDATE 是否真的走索引并控制锁范围
不能只信 EXPLAIN SELECT。必须交叉验证执行计划、锁视图和死锁日志：
- MySQL 8.0+ 运行
EXPLAIN FORMAT=TRADITIONAL UPDATE ...，重点看key是否非NULL、rows是否接近实际匹配数 - 若
Extra出现Using where; Using index condition但key为空，说明索引未生效 - 事务中执行
UPDATE后不提交，立刻查performance_schema.data_locks，观察LOCK_DATA是否大量非预期主键值 - 开启
innodb_print_all_deadlocks = ON，从 error log 看锁住的记录 ID 分布：离散 → 安全；连续大片 → 已锁扩大
分批更新和隔离级别选择是关键缓解点
即使有索引，大范围更新仍可能引发高并发阻塞。更危险的是，这种锁扩大不是性能问题，而是并发破坏问题——一个慢 UPDATE 就可能堵住后续所有 DML。
- 避免
DELETE FROM logs WHERE created_at 直接执行，改用 <code>LIMIT 1000循环，每次提交后释放锁 - 优先按主键范围切片（如
id BETWEEN ? AND ?），比ORDER BY + LIMIT更稳定，减少排序开销带来的锁持有时间延长 - 如果业务能接受不可重复读，把隔离级别设为
READ-COMMITTED，可避免 Gap Lock 和 Next-Key Lock，显著减少锁冲突
真正容易被忽略的，是那些不报错、不慢、却悄悄锁住整张表的 SQL：它们在监控里可能只是“普通写入”，但一旦并发上来，就会让其他事务在 Updating 状态卡住十几秒甚至更久——问题不在语句本身，而在索引是否真实生效、以及你是否看过 performance_schema.data_locks 里的锁分布。
