MySQL 8.0+ 创建 Invisible Index 需在 CREATE INDEX 或 ALTER TABLE 语句中添加 INVISIBLE 关键字，主键、唯一索引、全文索引和空间索引不支持该特性。
MySQL 8.0+ 怎么创建 Invisible Index
Invisible Index 是 MySQL 8.0 引入的特性，它让索引对优化器“不可见”，但物理上仍存在、仍被维护。创建时只需在
或
中加
关键字。
（已存在索引可直接设为 invisible）
注意：主键（PRIMARY KEY）和唯一约束（UNIQUE）相关的索引不能设为 invisible —— MySQL 会报错
全文索引（FULLTEXT）和空间索引（SPATIAL）也不支持 invisible，尝试会触发
为什么
不走 Invisible Index 却仍慢
因为 invisible 索引只是对优化器“隐身”，不参与执行计划选择；但它依然在 INSERT/UPDATE/DELETE 时被更新，写放大照旧。所以如果表写入频繁，性能下降可能比预期更明显。
用
能确认是否用了某个索引；invisible 索引不会出现在输出里
但用
会看到
列值为
容易误判的点：即使你手动加了
，优化器也会忽略 invisible 索引，直接报错
（不是拼写错误，是“逻辑上不可用”）
如何临时“启用”一个 Invisible Index 做实验
没有运行时开关，必须显式修改索引可见性。但可以快速切回，适合 A/B 计划验证。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
启用：
禁用：
这个操作是 instant DDL（MySQL 8.0.12+），不锁表，但要注意：它会触发一次元数据锁（MDL），如果此时有长事务正在查该表，
会等 —— 容易卡住
别在高峰期批量改多个索引 visibility，每个
都是独立 MDL 请求
哪些场景真该用 Invisible Index
它不是用来“先建着再说”的占位符，而是为索引下线提供灰度路径。
想删一个疑似无用索引，但不敢直接
？先
，观察一周慢查询日志和
中的
上线新复合索引前，把旧单列索引设为 invisible，对比 QPS 和延迟变化
注意陷阱：如果应用层有
，而你把对应索引设 invisible，查询会直接失败，不是降级走全表扫描
备份工具（如
mysql
dump）默认不导出 invisible 索引，但物理备份（xtrabackup）会保留 —— 恢复后仍是 invisible 状态，这点常被忽略
真正难的是判断“这个索引到底有没有被隐式依赖”：比如某 ORM 自动生成
，或 DBA 写的巡检脚本硬编码了索引名。invisible 不解决这类耦合，只暴露它们。
CREATE INDEXALTER TABLEINVISIBLECREATE INDEX idx_name ON t1(col1) INVISIBLE;ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE;ER_UNSUPPORTED_INDEX_ALTERER_NOT_SUPPORTED_YETSELECTEXPLAIN FORMAT=TREESHOW INDEX FROM t1VisibleNOUSE INDEX(idx_name)ER_KEY_DOES_NOT_EXITSALTER TABLE t1 ALTER INDEX idx_name VISIBLE;ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE;ALTERALTERDROPINVISIBLEperformance_schema.table_io_waits_summary_by_index_usageCOUNT_STARFORCE INDEXFORCE INDEX