innodb行锁加在聚簇索引叶子节点的索引记录上，而非抽象数据行；主键索引即聚簇索引，其叶子节点存储完整数据行，故锁直接作用于该索引项；无主键时使用隐式row_id构建聚簇索引，锁亦加于其上。
主键索引的聚簇特性直接决定行锁加在哪儿——InnoDB 的行锁不是加在“数据行”上，而是加在聚簇索引的叶子节点记录上。没有聚簇索引，就没有真正意义上的“行锁”，只有索引记录锁。
行锁本质是聚簇索引记录锁
InnoDB 文档明确说：行级锁（RECORD LOCK）作用对象是索引记录（index record），不是表中抽象的“某一行”。而聚簇索引的叶子节点就是真实数据行本身，所以对主键字段做 UPDATE 或 SELECT ... FOR UPDATE 时，锁直接落在聚簇索引 B+ 树的对应叶子页记录上。
这意味着：
- 即使你
WHERE id = 123更新，锁住的也不是“id=123 这条记录”，而是聚簇索引里 key=123 那条索引项（它同时就是数据） - 如果表没主键，InnoDB 用隐式
ROW_ID构建聚簇索引，那锁就加在那个不可见的ROW_ID值上——你查information_schema看不到，但锁确实存在 - 二级索引上的锁（比如
WHERE name = 'Alice'）只是先锁二级索引项，再通过回表拿到主键值后，最终还是要去聚簇索引上加锁——否则无法保证一致性
没有主键时锁行为会变得不可控
当表缺失显式主键且无 NOT NULL UNIQUE 列时，InnoDB 自动生成 6 字节隐式 ROW_ID 作为聚簇索引键。这个 ROW_ID 是全局自增、不可见、不可预测的。
后果很实际：
- 你执行
SELECT * FROM t WHERE id = 100 FOR UPDATE，但表根本没id字段？那这条语句会全表扫描，锁住所有聚簇索引记录（即全表锁） - 并发插入时多个事务可能竞争同一个
ROW_ID分配页，引发innodb_row_lock_waits上升，且锁等待堆栈里看不到具体字段名，只显示PRIMARY——你根本不知道它锁的是哪个逻辑行 -
EXPLAIN FORMAT=TRADITIONAL看不到访问路径是否走聚簇索引，因为优化器压根不把隐式ROW_ID当作可选驱动列
UPDATE 主键值会触发双重锁竞争
更新主键字段（如 UPDATE t SET id = 200 WHERE id = 100）不是简单修改一个值，而是等价于：DELETE 原聚簇索引记录 + INSERT 新记录。这导致两个独立的锁操作：
- 先在原
id=100对应的聚簇索引位置加X锁（用于删除） - 再在新
id=200应该插入的位置加X锁（用于插入） - 如果另一个事务正要
SELECT ... FOR UPDATE WHERE id = 200，就可能和这个 UPDATE 形成循环等待——典型死锁场景
这种双重锁路径只存在于聚簇索引更新中；二级索引更新（如 UPDATE t SET name = 'Bob' WHERE id = 100）只锁聚簇索引记录一次，风险低得多。
唯一索引冲突检测也依赖聚簇索引定位
当你插入一条违反 UNIQUE 约束的记录，InnoDB 不是先查二级索引再比对，而是：先在二级索引上尝试插入，发现重复后，立刻用该二级索引叶子节点存的主键值，跳转到聚簇索引里定位冲突行，然后对其加 S 锁（防止被删/改），再报错。
所以：
- 如果二级索引存的主键值是
NULL（比如联合唯一索引含可空列），聚簇索引定位失败，冲突检测可能漏判或误判 - 大字段（
TEXT/BLOB）溢出页不参与唯一约束校验，但聚簇索引定位仍需读溢出页——哪怕你只插主键和唯一列，也可能因额外 IO 拖慢冲突检测 -
INSERT ... ON DUPLICATE KEY UPDATE的“duplicate key”判断，底层就是靠聚簇索引快速确认是否存在同主键/同唯一键的物理记录
真正容易被忽略的点在于：事务隔离级别（比如 READ COMMITTED vs REPEATABLE READ）影响的是“锁的持续时间”和“是否加间隙锁”，但锁加在哪、怎么定位目标记录，完全由聚簇索引结构决定——无论你设什么隔离级别，WHERE id = ? 永远只锁聚簇索引叶子节点，不会错跑到二级索引上去。
