不可见索引让优化器默认忽略，但持续维护写入开销与唯一性校验；新建用CREATE INDEX ... INVISIBLE，已有索引须用ALTER TABLE ... ALTER INDEX ... INVISIBLE切换，EXPLAIN不显示、FORCE INDEX报错，验证需查INFORMATION_SCHEMA.STATISTICS并对比真实执行计划。
不可见索引不是“关掉索引”，而是让优化器在默认情况下彻底忽略它——写入开销、磁盘占用、唯一性校验全在，但执行计划里压根不出现。直接删索引风险高，用 INVISIBLE 才是安全验证真实影响的正确路径。
怎么创建或切换索引为不可见状态
新建索引时加 INVISIBLE 最稳妥，避免后续 ALTER 可能触发的元数据锁（MDL）等待；已有索引必须用标准语法切换，其他写法会报错。
-
CREATE INDEX idx_user_status ON users(status) INVISIBLE;—— 新建即不可见，秒级完成 -
CREATE UNIQUE INDEX idx_email ON users(email) INVISIBLE;—— 唯一索引支持，但若该列是隐式主键（表无显式PRIMARY KEY且 email 是首个UNIQUE NOT NULL字段），会报ERROR 3522 -
ALTER TABLE orders ALTER INDEX idx_created_at INVISIBLE;—— 唯一合法切换方式，8.0.12+ 是 instant DDL，不重建表，但仍有短时 MDL 等待 - 禁止写成
ALTER TABLE t MODIFY INDEX ... INVISIBLE或SET INVISIBLE，MySQL 直接报ERROR 1064
为什么 EXPLAIN 看不到不可见索引
这不是 bug，是设计行为：优化器在生成执行计划前就过滤掉了 IS_VISIBLE = 'NO' 的索引，EXPLAIN 根本不会把它放进候选集。只看 SHOW INDEX 的 Visible 列容易误判，必须双重验证。
- 查系统表确认：
SELECT IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'orders' AND INDEX_NAME = 'idx_created_at';—— 返回字符串'NO'才算设置成功 - 跑真实查询对比：
EXPLAIN SELECT * FROM orders WHERE created_at > '2026-01-01';—— 若之前走该索引，现在key为空或换成别的索引，才说明生效 - 别信
SHOW INDEX FROM t的Comment字段（恒为NULL），也别依赖旧版客户端输出，部分 ORM 或运维脚本硬编码列序会漏掉Visible列
FORCE INDEX 能否绕过不可见限制
不能。一旦索引设为 INVISIBLE，FORCE INDEX 会直接报错 ERROR 1176 (42000): Key 'idx_name' doesn't exist in table 't1' —— 优化器在解析阶段就认定它不存在，不是“跳过”，而是“注销”。
- ORM 框架可能隐式插入 hint：Django 的
.extra(index='idx_name')、MyBatis 的<hint>USE INDEX(idx_name)</hint>都会触发此错误 - 灰度测试前必须全局 grep 代码库里的
FORCE INDEX、USE INDEX、IGNORE INDEX关键词 - 压测需要对比“有/无该索引”的效果时，得临时打开会话开关：
SET SESSION optimizer_switch='use_invisible_indexes=ON';，再跑EXPLAIN FORMAT=JSON查used_indexes
测试期间最容易被忽略的写入成本问题
很多人以为“看不见=不维护”，其实相反：INSERT/UPDATE/DELETE 仍照常更新 B+ 树页、占用 buffer pool、产生 redo log。隐藏索引只省掉了“被选中”的那一步，写入延迟和磁盘空间一分不少。
- 观察指标不能只盯查询 QPS，必须同步压测写入吞吐（比如用 Sysbench 的
oltp_write_only场景） - 如果某索引写入压力大、查询几乎不用，隐藏它只是掩盖问题；真要降负载，最终还得
DROP INDEX - 备份恢复后行为可能突变：
mysqldump默认不导出INVISIBLE关键字，还原后索引变回VISIBLE；xtrabackup物理备份保留元数据，但需确认版本兼容性
