不可见索引是生产环境索引验证的安全阀，通过ALTER TABLE ALTER INDEX INVISIBLE秒级切换可见性，仅修改元数据不触碰B+树、不锁表、不影响写入，但不释放磁盘空间；优化器默认忽略它，EXPLAIN无key属正常；主键、外键依赖等索引不可设为不可见；备份恢复后状态可能丢失，需手动校验；验证后应及时删除，避免冗余负担。
不可见索引不是“让查询变快”的工具，而是专为生产环境设计的索引验证安全阀——它能让你在不删索引、不重建、不锁表的前提下，真实观察“没了这个索引会不会慢”。
ALTER TABLE ALTER INDEX INVISIBLE 为什么秒级且不影响线上写入
这条语句只修改 INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE 字段，不碰 B+ 树、不重写数据页、不触发元数据锁（MDL）长等待。哪怕表有千万行，执行耗时也是毫秒级。对比 DROP INDEX，后者要全量重建索引结构，高峰期可能卡住 DML 数分钟甚至更久。
- 长事务未提交时仍可能短暂阻塞，但阻塞的是元数据锁，不是行锁或表锁
- 写入延迟完全不受影响：INSERT/UPDATE/DELETE 依然同步更新该索引的 B+ 树页、产生 redo log、占用 buffer pool
- 磁盘空间不会释放，别指望靠设成 INVISIBLE 来“腾地方”或“减负载”
EXPLAIN 看不到不可见索引？这是正常行为，不是故障
默认情况下优化器压根不把 IS_VISIBLE = 'NO' 的索引纳入候选集，所以 EXPLAIN 的 key 字段为空，或走其他索引，这恰恰说明它生效了。很多人误以为“没变化=没生效”，其实是理解反了。
- 验证是否真被忽略，得对比两种会话状态：
SET SESSION optimizer_switch = 'use_invisible_indexes=off'（默认） vs=on -
FORCE INDEX(idx_name)会直接报错ERROR 1176 (HY000): Key 'idx_name' doesn't exist，这不是 bug，是优化器在解析阶段就已注销该索引 -
SHOW INDEX FROM t1的Visible列可能被旧脚本漏读，唯一可靠方式是查INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE
主键、唯一约束、外键依赖索引不能设为不可见，必须提前检查
MySQL 强制禁止对主键（含隐式主键）设 INVISIBLE，执行直接报错 ERROR 3522 (HY000): Primary key cannot be invisible。同样受限的还有外键引用的唯一索引、全文索引、空间索引——它们不是“不支持语法”，而是语义上不允许绕过约束校验。
- 唯一约束索引设为不可见后，INSERT/UPDATE 仍会检查唯一性，失败逻辑不变
- 检查前先跑：
SELECT INDEX_NAME, CONSTRAINT_NAME, INDEX_TYPE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't1'，过滤掉INDEX_TYPE IN ('FULLTEXT', 'SPATIAL')和主键相关项 - 分区表上对某一分区设 INVISIBLE，REORGANIZE PARTITION 可能重置所有分区索引可见性，需事后复查
备份恢复后 INVISIBLE 状态可能丢失，xtrabackup 尤其危险
mysqldump 默认保留 /*!80000 INVISIBLE */ 注释，但 xtrabackup 这类物理备份工具不保存该元数据。恢复后索引自动变回 VISIBLE，而你完全不知情——等于白做了验证。
- 用 xtrabackup 恢复后，必须立刻执行：
SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE IS_VISIBLE = 'NO' - ORM 或应用层硬编码了
FORCE INDEX或USE INDEX的 SQL，设为不可见后会直接失败，上线前必须全局扫描代码、配置、SQL 注释 - 观察周期建议 ≥24 小时，覆盖业务波峰波谷；真正难判断的不是单条 SQL 是否退化，而是 Handler_read_next 突增、慢日志里同类查询平均耗时上升、应用层超时告警频次变化
最易被忽略的一点：INVISIBLE 索引长期挂着反而增加系统负担——它不省空间、不减写开销、不降 buffer pool 压力，只省掉了“被选中”那一步。验证完该删就得删，别留着当摆设。
