MySQL 8.0+ 创建 Invisible Index 需在 CREATE INDEX 或 ALTER TABLE 语句中添加 INVISIBLE 关键字，主键、唯一索引、全文索引和空间索引不支持该特性。
MySQL 8.0+ 怎么创建 Invisible Index
Invisible Index 是 MySQL 8.0 引入的特性，它让索引对优化器“不可见”，但物理上仍存在、仍被维护。创建时只需在 CREATE INDEX 或 ALTER TABLE 中加 INVISIBLE 关键字。
CREATE INDEX idx_name ON t1(col1) INVISIBLE;-
ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE;（已存在索引可直接设为 invisible） - 注意：主键（PRIMARY KEY）和唯一约束（UNIQUE）相关的索引不能设为 invisible —— MySQL 会报错
ER_UNSUPPORTED_INDEX_ALTER - 全文索引（FULLTEXT）和空间索引（SPATIAL）也不支持 invisible，尝试会触发
ER_NOT_SUPPORTED_YET
为什么 SELECT 不走 Invisible Index 却仍慢
因为 invisible 索引只是对优化器“隐身”，不参与执行计划选择；但它依然在 INSERT/UPDATE/DELETE 时被更新，写放大照旧。所以如果表写入频繁，性能下降可能比预期更明显。
- 用
EXPLAIN FORMAT=TREE能确认是否用了某个索引；invisible 索引不会出现在输出里 - 但用
SHOW INDEX FROM t1会看到Visible列值为NO - 容易误判的点：即使你手动加了
USE INDEX(idx_name)，优化器也会忽略 invisible 索引，直接报错ER_KEY_DOES_NOT_EXITS（不是拼写错误，是“逻辑上不可用”）
如何临时“启用”一个 Invisible Index 做实验
没有运行时开关，必须显式修改索引可见性。但可以快速切回，适合 A/B 计划验证。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 启用：
ALTER TABLE t1 ALTER INDEX idx_name VISIBLE; - 禁用：
ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE; - 这个操作是 instant DDL（MySQL 8.0.12+），不锁表，但要注意：它会触发一次元数据锁（MDL），如果此时有长事务正在查该表，
ALTER会等 —— 容易卡住 - 别在高峰期批量改多个索引 visibility，每个
ALTER都是独立 MDL 请求
哪些场景真该用 Invisible Index
它不是用来“先建着再说”的占位符，而是为索引下线提供灰度路径。
- 想删一个疑似无用索引，但不敢直接
DROP？先INVISIBLE，观察一周慢查询日志和performance_schema.table_io_waits_summary_by_index_usage中的COUNT_STAR - 上线新复合索引前，把旧单列索引设为 invisible，对比 QPS 和延迟变化
- 注意陷阱：如果应用层有
FORCE INDEX，而你把对应索引设 invisible，查询会直接失败，不是降级走全表扫描 - 备份工具（如 mysqldump）默认不导出 invisible 索引，但物理备份（xtrabackup）会保留 —— 恢复后仍是 invisible 状态，这点常被忽略
真正难的是判断“这个索引到底有没有被隐式依赖”：比如某 ORM 自动生成 FORCE INDEX，或 DBA 写的巡检脚本硬编码了索引名。invisible 不解决这类耦合，只暴露它们。
