select for update在事务中对查询命中的记录加排他锁，锁范围取决于索引使用与隔离级别，可能为行锁、间隙锁、临键锁或表锁；锁在事务提交或回滚时释放，未走索引会升级为表锁。
意向锁不是你手动加的，是InnoDB自动塞进去的
很多人一看到IS、IX就下意识去写LOCK TABLE ...或者查SELECT ... LOCK IN SHARE MODE有没有触发它——其实根本不用操心加不加。只要事务对某行用了SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE，InnoDB就在背后悄悄给整张表加上IX或IS锁，你查INFORMATION_SCHEMA.INNODB_TRX也看不到显式记录，它只存在于锁结构内部。
你唯一能“感知”它的场景，是当另一个事务试图对整张表加LOCK TABLE ... WRITE或SELECT ... FOR UPDATE（无WHERE条件）时被卡住——那不是行锁在拦路，是意向锁在报信。
IS和IX之间完全兼容，但它们会拦住真正的表锁
IS和IX本身从不互相阻塞：一个事务持IS，另一个事务照样能加IX；反过来也成立。它们真正的价值，在于和真正的表级锁（S锁、X锁）冲突：
- 有
IS存在 → 表示“有人正在读某些行”，所以不允许其他事务加整表X锁（比如LOCK TABLE t WRITE） - 有
IX存在 → 表示“有人正在写某些行”，所以不允许加整表S锁（比如LOCK TABLE t READ）或X锁 - 哪怕只有一行被
FOR UPDATE锁住，整张表的IX就已生效，后续任何表级写操作都会等
为什么不能跳过意向锁直接查行锁？性能差太多
假设没意向锁，事务B想对test4加表级X锁，就得扫描全部1000万行，逐个检查每行有没有被其他事务的S或X行锁占用——这开销不可接受。
有了意向锁，InnoDB只需做一次判断：show engine innodb status\G里搜TABLE LOCK段，看当前表有没有IS或IX记录。有，就立刻拒绝；没有，才往下走。这个“一次判断”就是意向锁存在的全部意义。
注意：IS/IX是表级锁，但它们自己不阻止任何行操作——它们只是“告示牌”，不拦人，只提醒。
容易忽略的关键点：索引缺失会让意向锁失效成表锁
意向锁起作用的前提是InnoDB真正在用行锁。如果SELECT ... FOR UPDATE里的WHERE条件没走索引（比如对非索引字段查询），InnoDB会退化为锁全表——这时你看到的就不是IX，而是真正的表级X锁，IS/IX机制完全绕过。
换句话说：IS/IX只在行锁生效时才有存在感；一旦降级为表锁，它就失去协调意义，反而成了累赘信号。所以排查锁问题，第一件事永远是确认执行计划是否走了索引。
