不可见索引是优化器默认跳过但物理仍维护的索引，创建时加INVISIBLE关键字（如CREATE INDEX idx_user_status ON users(status) INVISIBLE），仅支持InnoDB B-tree索引，主键、FULLTEXT和SPATIAL索引不支持；ALTER TABLE ALTER INDEX INVISIBLE可切换已有索引状态，毫秒级完成；需通过INFORMATION_SCHEMA.STATISTICS确认IS_VISIBLE='NO'并排除optimizer_switch干扰，FORCE/USE INDEX对其无效。
不可见索引不是“隐藏界面”，而是让优化器默认跳过它——写入开销、磁盘占用、唯一性校验全在，但执行计划里压根不出现。生产环境测试前必须确认它真被忽略，否则观察结果全是假阳性。
CREATE INDEX 时直接加 INVISIBLE 关键字
新建索引就设为不可见，避免后续 ALTER 的元数据锁风险，也省去验证切换状态的步骤：
-
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 - 不支持
FULLTEXT或SPATIAL索引，仅限InnoDB的 B-tree 类型
ALTER TABLE ALTER INDEX INVISIBLE 切换已有索引
已有索引不能用 MODIFY INDEX 或 SET INVISIBLE，语法错误；必须用标准 DDL：
-
ALTER TABLE orders ALTER INDEX idx_created_at INVISIBLE;—— 正确，只改元数据，毫秒级 -
ALTER TABLE orders ALTER INDEX idx_created_at VISIBLE;—— 回滚也一样快，无需重建 - 执行前务必查
INFORMATION_SCHEMA.STATISTICS确认该索引非主键：SELECT INDEX_NAME, CONSTRAINT_TYPE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND INDEX_NAME = 'idx_created_at';，若CONSTRAINT_TYPE = 'PRIMARY KEY'，直接失败
验证是否真被优化器忽略
别信 SHOW INDEX 的 Visible: NO 就算完事——要双重确认：
- 查系统表：
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为空或换成别的索引，才说明生效 - 警惕
optimizer_switch干扰：执行SELECT @@optimizer_switch LIKE '%use_invisible_indexes=on%';，如果返回1，说明会话开启了隐形索引可见性，EXPLAIN会误判；临时关掉：SET SESSION optimizer_switch = 'use_invisible_indexes=off';
FORCE INDEX 和 USE INDEX 都会失败
这是最容易踩的坑：不可见索引对强制提示完全免疫，不是 bug，是设计逻辑：
-
SELECT * FROM orders USE INDEX (idx_created_at) WHERE created_at > '2026-01-01';→ 直接报错：ERROR 1176 (42000): Key 'idx_created_at' doesn't exist in table 'orders' -
SELECT * FROM orders FORCE INDEX (idx_created_at) WHERE created_at > '2026-01-01';→ 同样报错 - 想对比“启用 vs 禁用”效果？必须开开关：
SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */ * FROM orders WHERE created_at > '2026-01-01';（MySQL 8.0.22+ 支持）
真正难的是判断“这个索引到底有没有被业务依赖”——performance_schema.table_io_waits_summary_by_index_usage 的 COUNT_STAR = 0 只是起点，得结合慢查询日志突增、Handler_read_next 暴涨、应用层超时告警一起看，至少观察 24 小时。别忘了，即使它不可见，INSERT/UPDATE/DELETE 仍照常维护它，写入性能不会变好。
