不可见索引让优化器彻底跳过该索引生成执行计划，但写入开销、磁盘占用和唯一性校验均不变；其核心价值是通过毫秒级元数据修改（仅更新is_visible标志）安全验证删索引影响，避免小时级重建风险。
不可见索引不是“让索引变透明”，而是让优化器在生成执行计划时彻底跳过它——但写入开销、磁盘占用、唯一性校验全照旧。它真正价值在于：用毫秒级元数据变更，代替小时级索引重建，安全验证“删了这个索引，到底会不会出事”。
ALTER INDEX INVISIBLE 为什么能秒级生效
它只改 INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE 字段，不碰 B+ 树页、不重建索引结构、不加元数据锁（MDL）。对比 DROP INDEX：后者要重写整个索引，千万行表可能卡住写入数小时。
-
ALTER TABLE t ALTER INDEX idx_name INVISIBLE执行后立刻生效，SHOW INDEX FROM t \G中可见Visible: NO - 主键（含隐式主键）、全文索引、空间索引不支持设为不可见，否则报错
ERROR 3522 - 8.0.12+ 支持 instant DDL，但仍有极短 MDL，高并发写入时可能短暂阻塞
EXPLAIN 看不到不可见索引？那就别信 EXPLAIN
这不是 bug，是设计行为：EXPLAIN 压根不会列出不可见索引——优化器根本没把它放进候选集。单靠它判断“是否生效”会漏掉关键信号。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 普通查询：
EXPLAIN SELECT * FROM t WHERE col = 1→key字段为空或走其他索引，只能说明它没被选中，不能证明它被忽略 - 强制验证：
EXPLAIN SELECT * FROM t USE INDEX (idx_name) WHERE col = 1→ 若报错Unknown index 'idx_name'，说明索引名错了；若走了该索引，说明它物理存在且可用 - 别信
SHOW INDEX的Comment字段（恒为NULL），要看Visible列或查INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE
怎么验证它真没被用，而不是“假装没用”
光看 EXPLAIN 不够，得盯真实负载变化。尤其容易被忽略的是触发器内嵌的 SELECT ——它不受外部开关影响，必须单独捕获其执行计划。
- 开启会话级开关：
SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */ * FROM t WHERE ...，比全局SET GLOBAL安全得多 - 压测时必须查
performance_schema.table_io_waits_summary_by_index_usage，确认COUNT_STAR是否归零；否则可能只是“没走到”，不是“没被考虑” - 触发器体内的
SELECT查询，需在触发器 SQL 中加EXPLAIN FORMAT=JSON或用SELECT ... INTO @var+SHOW PROFILE捕获内部计划 - ORM 或应用代码里写了
USE INDEX(idx_name)的语句，设为不可见后会直接报错ERROR 1176，上线前必须全量扫描代码和配置
最容易误判的点：它不省空间、不减写开销
这是最常踩的坑。不可见索引只改优化器决策路径，不改物理维护行为：每次 INSERT/UPDATE/DELETE 仍会更新该索引的 B+ 树页，磁盘空间照占，写延迟照扣。想靠它“缓解负载”是典型误判。
- 备份恢复后可见性可能丢失：
mysqldump保留INVISIBLE属性，xtrabackup不保存，恢复后需手动查IS_VISIBLE确认 - 观察周期建议 ≥24 小时，覆盖业务波峰波谷；期间异常只需一条
ALTER INDEX VISIBLE秒级回滚 - 真正难的是判断“它到底支不支撑关键路径”——不能只信单条
EXPLAIN，得盯慢日志、performance_schema和真实 DML 延迟变化。一旦漏掉这些信号，就容易把救命索引当冗余给“藏没了”
