UPDATE语句默认加行级排他锁（X锁）；有索引时精确锁定匹配行，无索引时全表扫描并锁所有扫描行，即使WHERE未命中数据也会锁搜索路径上的间隙。
UPDATE 语句默认加什么锁？
MySQL（InnoDB）中，UPDATE 语句在可重复读（RR）隔离级别下，默认对匹配的行加 排他锁（X 锁），且是**行级锁**；但实际是否真锁住“一行”，取决于有没有可用的索引。
如果没有 WHERE 条件，或 WHERE 条件无法使用索引（如 LIKE '%abc'、字段类型隐式转换、函数包裹列），InnoDB 会退化为全表扫描，并对所有扫描过的记录加 X 锁——此时接近“锁表”效果，极易引发阻塞。
- 有主键或唯一索引：只锁匹配的那几行（精确匹配）
- 有普通索引但非唯一：可能触发
next-key lock（间隙锁 + 行锁），锁住值区间，防止幻读 - 无索引：全表扫描，每条被扫描的记录都加 X 锁，性能差、冲突高
为什么两个 UPDATE 会互相等待甚至死锁？
死锁不是锁太多，而是**加锁顺序不一致**导致的循环等待。比如事务 A 先更新 id=1 再更新 id=2，事务 B 反过来先更新 id=2 再更新 id=1，就可能触发死锁。
InnoDB 检测到死锁后，会主动回滚其中代价较小的事务（通常行锁数量少的那个），抛出错误：Deadlock found when trying to get lock; try restarting transaction。
- 避免方式：所有业务逻辑中，对多行更新严格按相同顺序（如按
id ASC排序后再更新） - 不要在应用层分多次
UPDATE同一批数据；尽量合并为单条语句，或用SELECT ... FOR UPDATE预加锁并统一顺序 - 监控死锁：查
SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK区域
UPDATE 的 WHERE 条件没命中任何行，还会上锁吗？
会。InnoDB 仍会对 **搜索路径上的索引记录（包括间隙）** 加锁，即使最终没找到数据。这是为了防止幻读，属于 next-key lock 的正常行为。
Modoer 是一款以本地分享，多功能的点评网站管理系统。采用 PHP+MYSQL 开发设计，开放全部源代码。因具有非凡的访问速度和卓越的负载能力而深受国内外朋友的喜爱，不局限于商铺类点评，真正实现了多类型的点评，可以让您的网站点评任何事与物，同时增加产品模块，也更好的网站产品在网站上展示。Modoer点评系统 2.5 Build 20110710更新列表1.同步 旗舰版系统框架2.增加 限制图片
例如表 t(id PK, name)，当前只有 id=1 和 id=5 两行，执行：
UPDATE t SET name='x' WHERE id = 3;
虽然没更新任何行，但 InnoDB 会在 (1, 5) 这个间隙上加锁，阻止其他事务插入 id=3 或 id=4 的记录。
- 这种“空更新也锁间隙”的行为，在高并发插入场景下容易被忽略，成为隐形瓶颈
- 若确定不需要防幻读（如日志类表），可考虑改用
READ COMMITTED隔离级别，此时只加行锁，不加间隙锁 - 用
EXPLAIN FORMAT=tree查看执行计划，确认是否真的走索引、扫描范围多大
如何验证某条 UPDATE 到底锁了哪些行/间隙？
直接查 information_schema.INNODB_TRX 和 INNODB_LOCKS（MySQL 8.0+ 已移除该表）不行——更可靠的是结合 performance_schema.data_locks：
SELECT ENGINE_TRANSACTION_ID AS trx_id,
OBJECT_SCHEMA,
OBJECT_NAME,
INDEX_NAME,
LOCK_TYPE,
LOCK_MODE,
LOCK_DATA
FROM performance_schema.data_locks
WHERE ENGINE_TRANSACTION_ID IN (
SELECT TRX_ID FROM information_schema.INNODB_TRX
WHERE TRX_STATE = 'LOCK WAIT' OR TRX_STATE = 'RUNNING'
);
注意：LOCK_DATA 显示的是被锁记录的索引字段值（如主键值）或间隙边界（如 3 表示间隙 (1,3) 或 (3,5)），需结合 LOCK_MODE（如 RECORD、GAP、NEXT-KEY）一起解读。
- 开启前确保
performance_schema已启用，且data_locks表已打开（SET GLOBAL performance_schema = ON;） -
LOCK_MODE = 'X,GAP'表示只锁间隙，不影响已有记录的更新，但会阻塞插入 - 生产环境慎用长事务 + 大范围 UPDATE，锁持有时间越长，冲突概率越高
实际并发更新中最容易被绕开的问题，是“自以为只改一行，结果因索引失效锁了一整页”，或者“空 WHERE 更新却意外锁住关键间隙”。排查时别只盯 SQL 逻辑，一定先看执行计划和锁视图。