mysql行级锁实际锁的是索引项：若where命中二级索引，则先锁该二级索引项，再根据其存储的主键值回表锁对应聚簇索引记录，二者缺一不可。
MySQL锁住一行数据时，实际锁的是索引项，不是“行”本身；聚簇索引（主键索引）和二级索引之间存在天然的联动关系，这种联动直接决定了哪些索引会被连带加锁。
为什么UPDATE语句会同时锁二级索引和主键索引
InnoDB执行UPDATE时，如果WHERE条件命中的是二级索引（比如KEY idx_user_item(user_id, item_id, status)），它必须先通过该索引定位记录，再回表——也就是用查到的主键值去聚簇索引中读取/修改完整行。这个过程分两步：
- 第一步：在二级索引树上查找匹配项 → 对匹配的二级索引项加X锁（或Next-Key Lock）
- 第二步：用查得的主键值去聚簇索引中定位并更新 → 对对应主键记录加X锁
这两把锁都属于同一事务，且必须同时持有才能保证原子性。如果另一个并发事务反向操作（比如先锁主键、再锁该二级索引），就极易触发死锁。
SELECT ... FOR UPDATE在非唯一二级索引上的锁范围不止“等值”
在RR隔离级别下，对非唯一二级索引做等值查询加锁（如SELECT * FROM team WHERE position_no = 6 FOR UPDATE），InnoDB不会只锁住position_no = 6那一条索引记录。
- 它实际加的是
Next-Key Lock：即(5, 6]区间（假设前一个position_no是5） - 这个锁覆盖了索引项本身（Record Lock）+ 索引项之前的间隙（Gap Lock）
- 由于二级索引叶子节点只存主键值，InnoDB还需根据这些主键值去聚簇索引中加对应X锁——也就是说，多个主键记录可能被一并锁定
这就是为什么看似只查position_no = 6，却可能导致插入position_no = 7也被阻塞：间隙锁已覆盖(6, +∞)，而插入新记录需写入该间隙。
没有主键或索引缺失时，锁会扩散到整个聚簇索引
当UPDATE或DELETE语句无法利用任何索引（例如WHERE user_name LIKE '%abc%'且user_name无索引），InnoDB无法快速定位目标行，只能走聚簇索引全扫描。
- 每扫描一行，就对聚簇索引中该主键记录加X锁（即使最终不满足WHERE条件）
- 结果是：整张表的主键索引几乎全被锁定，等效于“准表锁”
- 此时若另一事务试图按二级索引更新某行，就会因等待主键锁而陷入长等待，甚至触发
Lock wait timeout exceeded
更危险的是，这种全扫+逐行加锁的行为，在RR级别下还会伴随间隙锁，进一步扩大锁定范围。
唯一索引等值查询能避免聚簇索引锁扩散吗
可以，但有前提：必须是**唯一索引 + 等值查询 + 查询条件能命中索引**。
- 例如
SELECT * FROM user_item WHERE id = 123 FOR UPDATE（id是主键）→ 只锁聚簇索引中这一条 - 又如
SELECT * FROM user_item WHERE user_id = 100 AND item_id = 200 FOR UPDATE，若(user_id, item_id)是唯一联合索引 → InnoDB可精确匹配，只锁该二级索引项 + 对应主键项，不会锁间隙 - 但如果WHERE里多了一个
status 0，而status不在该联合索引中 → 索引无法覆盖过滤，服务器层回表后还要二次判断，InnoDB就得提前锁住更多主键行（因为不知道哪些最终会被过滤掉）
所以“唯一性”本身不保安全，关键在于**优化器能否在引擎层完成全部过滤**——这取决于索引是否覆盖所有WHERE字段，以及是否触发Using where。
