不可见索引不能代替监控，但能安全验证删除影响；执行ALTER TABLE t ALTER INDEX idx_name INVISIBLE毫秒完成，需查INFORMATION_SCHEMA.STATISTICS确认IS_VISIBLE='NO'，主键等特定索引会报ERROR 3522。
不可见索引不能代替监控，但能让你在不删索引的前提下，真实观察“删了它会不会变慢”——这是唯一可落地的试错方式。
怎么把索引设为不可见并确认生效
执行 ALTER TABLE t ALTER INDEX idx_name INVISIBLE 即可，毫秒级完成，不锁表、不重建 B+ 树。但别信 SHOW INDEX FROM t 的输出：它的 Visible 列在旧版客户端或硬编码脚本里可能被忽略；唯一可靠方式是查 INFORMATION_SCHEMA.STATISTICS：
SELECT INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't' AND INDEX_NAME = 'idx_name';
返回 IS_VISIBLE = 'NO' 才算成功。注意：PRIMARY KEY、隐式主键、外键依赖的唯一索引会直接报错 ERROR 3522 (HY000)，不能设为不可见。
为什么 EXPLAIN 看不到，以及怎么验证它真被忽略了
EXPLAIN 不显示不可见索引不是 bug，是设计行为：优化器在生成执行计划前就已过滤掉所有 IS_VISIBLE = 'NO' 的索引。所以你看到 key 字段为空，不代表它没生效，只说明它被跳过了。
- 验证是否真的被忽略：跑
EXPLAIN SELECT * FROM t WHERE col = 1;，确认没走该索引 - 验证是否仍物理存在：跑
EXPLAIN SELECT * FROM t USE INDEX (idx_name) WHERE col = 1;，若报错Unknown index 'idx_name'，说明索引名错了；若走了索引，说明它还在 - 更关键的是压测时临时启用：执行
SET SESSION optimizer_switch='use_invisible_indexes=ON'，再跑EXPLAIN FORMAT=JSON，看used_indexes是否出现目标索引
哪些地方会绕过不可见机制导致故障
不可见索引不是“隐身斗篷”，很多显式写法会直接暴露问题：
-
FORCE INDEX (idx_name)或USE INDEX (idx_name)的 SQL 会报错ERROR 1176 (42000): Key 'idx_name' doesn't exist in table 't'，哪怕索引物理存在——因为优化器解析阶段就认定它不存在 - ORM（如 Laravel、Django）配置或迁移脚本里硬编码了索引名，上线后可能触发报错或查询失败
- 备份恢复后行为不一致：
mysqldump默认导出INVISIBLE属性，但xtrabackup不保证保留，恢复后需手动查IS_VISIBLE确认 - 分区表上执行
ALTER TABLE ... REORGANIZE PARTITION可能重置所有分区索引的可见性，必须事后复查
观察期要盯什么指标才不算白等
设为不可见后只等 24 小时远远不够，真正难的是判断“它到底支不支撑关键路径”。不能只信单条 EXPLAIN，得交叉验证：
- 查
performance_schema.table_io_waits_summary_by_index_usage中COUNT_READ是否归零，但要注意：低频但关键的报表查询可能一周只跑一次，COUNT_READ = 0不等于“无用” - 盯慢查询日志：有没有新增的 >1s 查询，特别是原来稳定在 100ms 的语句突然飙升
- 看
Handler_read_next/Handler_read_rnd_next是否突增——说明优化器被迫走全表扫描或文件排序 - 应用层告警：超时、重试、熔断是否集中出现在某类接口，对应 SQL 是否恰好命中该索引字段
最常被忽略的一点：长期挂着不可见索引并不会降低写入开销——INSERT/UPDATE/DELETE 仍照常更新该索引的 B+ 树页、占 buffer pool、写 redo log。它只省掉了“被选中”的那一步决策成本。
