invisible索引对锁行为完全无影响，因其默认不被优化器选中，不参与加锁路径；锁范围仅取决于实际执行计划所用索引，唯一例外是显式开启optimizer_switch='use_invisible_indexes=on'。
INVISIBLE 索引本身不会扩大或改变事务的锁定范围。这是个常见误解——不可见索引对锁行为完全无影响。
MySQL 的行锁（如 RECORD LOCK）、间隙锁（GAP LOCK）和临键锁（NEXT-KEY LOCK）只取决于实际参与查询执行计划的索引，而 INVISIBLE 索引在默认情况下根本不会被优化器选中，也就不会进入执行引擎的加锁路径。
所以，如果你观察到“加锁变多/变少”，问题不在索引是否可见，而在：
-
EXPLAIN显示实际走的索引变了（比如从idx_a切到PRIMARY），导致扫描范围不同 - 隐式主键被触发（表无显式主键时，第一个
UNIQUE NOT NULL索引自动成为隐式主键，且不可设为INVISIBLE） - 事务中用了
FORCE INDEX，但该索引恰好是INVISIBLE→ 此时强制无效，优化器 fallback 到其他索引，锁范围可能意外扩大
为什么有人觉得“不可见索引影响了锁”？
典型误判场景：
- 把索引设为
INVISIBLE后，某条UPDATE ... WHERE x = ?变慢、锁等待增多 → 实际是优化器退回到全表扫描或主键聚簇索引扫描，锁住更多行 - 误以为
INVISIBLE索引仍参与 MVCC 或锁判断 → 它连 B+ 树遍历都不走，更不参与加锁逻辑 - 没检查
information_schema.INNODB_TRX和INNODB_LOCK_WAITS，仅凭业务超时就归因于索引可见性
如何验证锁行为没被 INVISIBLE 干扰？
直接看执行计划和锁监控：
- 运行
EXPLAIN FORMAT=tree或EXPLAIN ANALYZE，确认实际使用的索引不是那个INVISIBLE的 - 查
SELECT * FROM performance_schema.data_locks WHERE OBJECT_SCHEMA = 'db' AND OBJECT_NAME = 't1'，对比设为INVISIBLE前后锁记录的INDEX_NAME字段 - 用
SHOW ENGINE INNODB STATUS\G观察TRANSACTIONS段里的当前锁等待，看锁对象是否指向你刚设为INVISIBLE的索引名 —— 绝不会出现
optimizer_switch='use_invisible_indexes=on' 是唯一例外
只有显式开启这个开关后，INVISIBLE 索引才可能被选中执行，进而参与加锁。但这属于主动启用，不是默认行为，且线上严禁全局开启。
真正影响锁范围的，永远是「优化器最终选择哪个索引做定位」，而不是索引在数据字典里标着 YES 还是 NO 的 IS_VISIBLE。
