不可见索引不优化事务执行计划，仅让优化器默认跳过该索引；它不减少写入开销、磁盘占用或锁竞争，但可通过瞬时元数据操作（ALTER TABLE ... ALTER INDEX INVISIBLE）安全验证删除索引对事务稳定性的影响。
不可见索引本身不优化事务执行计划，它只是让优化器默认跳过某个索引——事务是否变快，取决于你原本依赖的索引是否真被误用、是否引发锁竞争或回表放大。关键不是“加 invisible 就提速”，而是用它安全验证“删掉这个索引会不会让事务更稳”。
ALTER TABLE ALTER INDEX INVISIBLE 是瞬时元数据操作，不影响事务并发
这条语句只改 INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE 字段，不重建索引、不锁表、不阻塞 DML。你在高峰期执行 ALTER TABLE orders ALTER INDEX idx_status INVISIBLE，事务照常提交，innodb_row_lock_waits 不会突增。
- 但注意：如果该索引是唯一约束支撑的（比如
UNIQUE (order_no)），设为不可见后，INSERT 仍会检查唯一性——冲突报错逻辑不变，只是优化器不再用它加速 WHERE 查找 - 主键索引、隐式主键（第一个
UNIQUE NOT NULL）无法设为不可见，执行直接报ER_PRIMARY_CANT_BE_INVISIBLE - MySQL 8.0.12+ 支持 instant DDL，但高并发写入下仍可能短暂持有 MDL 锁，建议避开秒级峰值窗口
FORCE INDEX 对 INVISIBLE 索引完全无效，别指望靠 hint 绕过
写 SELECT * FROM orders FORCE INDEX (idx_status) WHERE status = 'paid'，EXPLAIN 显示 key: NULL 或走了别的索引，这不是 bug，是设计行为：优化器在生成执行计划前就过滤掉了所有 IS_VISIBLE = 'NO' 的索引。
- 验证方式必须查元数据：
SELECT IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'orders' AND INDEX_NAME = 'idx_status' - ORM 框架（如 Django 的
.extra(index='idx_status')）若生成了 FORCE/USE INDEX，也会被无视——灰度前务必全局 grep 代码库 - 想临时启用它参与优化？只能开会话级开关：
SET SESSION optimizer_switch = 'use_invisible_indexes=on'，然后重跑 EXPLAIN
观察事务性能变化，重点盯 Handler_read_* 和慢日志，而非仅看 QPS
把索引设为不可见后，事务变慢往往不是因为查询慢了，而是因为原来走索引覆盖的 UPDATE 变成了回表，或唯一约束校验路径变长，导致行锁范围扩大、锁等待上升。
- 监控指标优先看：
Handler_read_next（索引扫描次数）、Handler_read_rnd_next（随机读行次数）、Innodb_row_lock_time_avg - 对比前后慢日志里相同事务模板的
Query_time和Lock_time，尤其关注UPDATE ... WHERE status = ?类型 - 写入压力大的场景（如订单状态批量更新），必须同步压测：Sysbench 的
oltp_write_only模式比只看 SELECT QPS 更能暴露问题
不可见索引仍参与写入维护，磁盘和 CPU 开销一分不少
很多人误以为“看不见=不干活”，其实 B+ 树页照样要分裂、合并、刷脏；INSERT/UPDATE/DELETE 依然触发该索引的变更日志；innodb_rows_inserted 统计值不会下降。
- 如果某索引写入开销大、查询几乎不用，隐藏它只是掩盖负载，真正降压得
DROP INDEX - 唯一索引设为不可见后，列值仍必须满足唯一性——违反时仍报
ER_DUP_ENTRY，不是静默忽略 - 跨版本迁移风险：MySQL 5.7 或更低版本解析含
INVISIBLE的mysqldump输出会失败；用--no-create-info手动建表会丢失可见性设置
最常被忽略的一点：不可见索引不是性能开关，而是优化器的“选择性失明”。它不减少物理 IO，也不缩短锁持有时间——你得靠观察真实事务的锁行为、回表深度、执行路径变化，才能判断它到底该留还是该删。
