MySQL中record locks等锁是否属于Intention Locks（意向锁）？

你提到的这几类锁和Intention Locks（意向锁）是完全独立的不同锁类型，仅部分触发语法存在重叠，二者不属于同一分类维度。

1. 意向锁的核心定位 #

意向锁是表级锁，作用是提前标识当前事务后续将要对表内行数据加共享锁（S锁）还是排他锁（X锁），避免后续全表级操作和行锁产生冲突。意向锁之间不会互相阻塞，仅会阻塞全表级的共享/排他锁操作。

2. 其他锁的分类归属（均不属于意向锁） #

你列出的几类锁均属于行级/区间类锁，和表级意向锁完全独立：

• 记录锁（Record Locks）：行级锁，仅锁住索引上的单条记录，一般在唯一索引等值查询且命中记录时触发，用于防止其他事务修改、删除当前命中的记录。
• 间隙锁（Gap Locks）：区间锁，锁住索引记录之间的间隙，或是首条索引之前、末条索引之后的空区间，唯一作用是防止其他事务往间隙中插入新记录，用于解决幻读问题。
• 临键锁（Next-key Locks）：记录锁+间隙锁的组合，是InnoDB默认的行锁算法，会同时锁住记录本身以及记录之前的间隙，范围查询时默认使用该锁。
• 插入意向锁（Insert Intention Locks）：注意名称中的「意向」仅为描述作用，它属于间隙锁的特殊子类，和表级意向锁没有关联。是事务执行INSERT操作前加的锁，允许多个事务往同一个间隙的不同位置插入数据时互不阻塞，提升插入并发度。
• 自增锁（AUTO-INC Locks）：针对AUTO_INCREMENT列的特殊表级锁，事务往带有自增列的表插入数据时获取，保证自增列生成的值连续有序，和意向锁完全无关。

3. 语法重叠的原因 #

FOR SHARE、FOR UPDATE是InnoDB提供的显式加锁语法指令，同一个指令执行时可能同时触发多个维度的锁，比如执行SELECT * FROM test WHERE id = 1 FOR UPDATE时，InnoDB会先给整个表加意向排他锁（IX），再给id=1的记录加记录锁，两类锁是同时生效的不同对象，并非同一种锁，因此会造成「使用相同指令属于同类锁」的误解。

内容的提问来源于stack exchange，提问作者Viktor