invisible index不是开关功能，而是优化器默认跳过的元数据标记；必须用alter table ... alter index ... invisible设置，主键等特定索引不支持，explain不显示属正常设计，验证需对比use index前后执行计划。
直接说结论：Invisible Index 不能“开启”，只能设为 INVISIBLE 或 VISIBLE；它不是开关功能，而是让优化器默认跳过该索引的元数据标记。平滑下线的核心动作是先设为不可见、观察影响、再决定删或留。
怎么把已有索引设为不可见（INVISIBLE）
必须用 ALTER TABLE ... ALTER INDEX ... INVISIBLE，其他方式无效：
-
ALTER TABLE orders ALTER INDEX idx_user_id INVISIBLE;—— 这是唯一可靠方式，8.0.12+ 是 instant DDL，不重建表，但会短暂持有元数据锁（MDL），高并发写入时可能排队 - 不能用
MODIFY INDEX、CHANGE INDEX，也不支持 GUI 工具（Workbench/DBeaver 等均无此功能） - 主键、第一个
UNIQUE NOT NULL索引（隐式主键）、全文索引、空间索引不支持，执行会报错ERROR 3522 (HY000): A primary key index cannot be invisible - 新建索引时可直接加
INVISIBLE：例如CREATE INDEX idx_status ON users(status) INVISIBLE;
为什么 EXPLAIN 看不到它，以及怎么确认真生效了
这不是 bug，是设计行为：优化器默认根本不把 INVISIBLE 索引纳入候选集，所以 EXPLAIN 的 key 字段为空或切换到别的索引，属于正常现象。
- 验证是否生效，必须做两步对比：
→EXPLAIN SELECT * FROM users WHERE status = 'active';看是否退化为全表扫描或走其他索引
→EXPLAIN SELECT * FROM users USE INDEX (idx_status) WHERE status = 'active';若能走该索引，说明物理存在且结构完好 - 别信
SHOW INDEX FROM users的Comment字段（恒为NULL），要看Visible列（8.0.12+）或查INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE，值为'NO'才对 - 刚执行完
ALTER就查IS_VISIBLE可能有毫秒级延迟，优先以EXPLAIN行为为准
压测和观察阶段必须绕开的三个坑
很多人以为设成 INVISIBLE 就万事大吉，实际落地常卡在这几个地方：
- 应用代码或 ORM 里写了
FORCE INDEX(idx_name)—— 这种显式强制会直接报错ERROR 1176 (42000): Key 'idx_name' doesn't exist in table 't1'，必须提前全局搜索并移除 - 备份恢复后行为可能突变：
mysqldump --no-data默认不导出INVISIBLE属性，还原后索引变回VISIBLE；xtrabackup 等物理备份工具也不保证保留该元数据 - 分区表上对某一分区设为不可见，其他分区不受影响；但执行
ALTER TABLE ... REORGANIZE PARTITION后，所有分区索引可见性可能被重置，需事后复查
什么时候该删，而不是一直挂着 INVISIBLE
设为 INVISIBLE 不减少任何写入开销——INSERT/UPDATE/DELETE 仍要维护该 B+ 树，磁盘空间照占，唯一性约束照校验。它只解决“选不选”的问题，不解决“存不存”的问题。
- 如果连续 24–48 小时观察到：
→ 慢查询日志中相同 SQL 的Rows_examined未明显上升
→performance_schema.events_statements_summary_by_digest中该语句平均耗时稳定
→Handler_read_next和Handler_read_rnd_next无异常飙升
→ 写入侧innodb_rows_inserted、innodb_buffer_pool_reads无变化
那基本可以确认这个索引确实没被有效利用 - 删之前强烈建议先
ALTER INDEX ... VISIBLE，确认业务无异常后再DROP INDEX，避免某些客户端工具或旧版 ORM 因扫描SHOW INDEXES而误判
真正容易被忽略的是：INVISIBLE 状态不会降低写入延迟，也不会释放磁盘空间；它只是个执行计划层的“软开关”，而很多团队把它当成了“性能优化手段”来用——结果发现 QPS 没涨，磁盘还在涨，写入延迟也没降。
