不可见索引不降低写开销或磁盘占用，仅让优化器默认忽略；设为不可见需用alter table ... alter index ... invisible（毫秒级），主键及隐式主键禁止设置，确认生效应查information_schema.statistics.is_visible='no'或观察explain执行计划退化。
不可见索引不是“关掉索引”，而是让优化器默认跳过它——写入开销、磁盘占用、唯一性校验全在，但执行计划里压根不出现。它解决的是“不敢删索引”这个真实痛点，而不是帮你省资源。
怎么把现有索引设为不可见并确认生效
操作本身是元数据级变更，毫秒完成，但必须避开主键和隐式主键这类硬限制：
-
ALTER TABLE orders ALTER INDEX idx_user_id INVISIBLE是唯一合法语法；写成MODIFY INDEX或SET INVISIBLE会报错ERROR 1064 - 主键（含显式
PRIMARY KEY和无主键时首个UNIQUE NOT NULL索引）禁止设为不可见，执行直接失败：ERROR 3522 (HY000): Primary key cannot be invisible - 验证不能只看
SHOW INDEX FROM orders\G的Comment字段（它恒为NULL），要查INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE，返回字符串'NO'才算成功 - 刚执行完
ALTER就查information_schema可能有毫秒级延迟，更可靠的方式是跑一次EXPLAIN SELECT * FROM orders WHERE user_id = 123：如果之前走该索引，现在变成type: ALL或换用别的索引，基本可确认生效
为什么 EXPLAIN 看不到不可见索引，以及怎么让它“临时现身”
EXPLAIN 默认完全无视不可见索引，这不是 bug，是设计行为——优化器生成执行计划前就过滤掉了所有 IS_VISIBLE = 'NO' 的索引。连 FORCE INDEX (idx_name) 都无效，会直接报错 ERROR 1176 (HY000): Key 'idx_name' doesn't exist。
想对比“有/无该索引”的真实影响，必须手动启用隐形索引参与优化：
- 会话级开关（推荐）：
SET SESSION optimizer_switch = 'use_invisible_indexes=on'，然后跑EXPLAIN；注意别被其他optimizer_switch设置干扰（比如use_index_extensions=off） - SQL 级提示（MySQL 8.0.22+）：
SELECT /*+ SET_VAR(optimizer_switch = "use_invisible_indexes=on") */ * FROM orders WHERE status = 'shipped'，再EXPLAIN - 切记两次
EXPLAIN必须在相同 session 下做，且确保没被全局optimizer_switch覆盖
线上灰度测试时最容易漏掉的三个信号
单条 SQL 的 EXPLAIN 结果只是表象，真实影响得靠生产负载说话：
- 盯
performance_schema.table_io_waits_summary_by_index_usage中的COUNT_STAR：归零只是基础参考，低频关键查询可能长期不触发，但一旦出问题就是超时告警 - 监控
Handler_read_*指标突增（如Handler_read_next、Handler_read_rnd_next），说明大量回表或全表扫描开始发生 - 慢查询日志里是否出现原本不慢的 SQL 突然
Query_time翻倍，尤其注意带ORDER BY、LIMIT的分页查询——它们对索引依赖极强
观察周期建议 ≥ 24 小时，覆盖完整业务波峰波谷；期间若异常，ALTER TABLE orders ALTER INDEX idx_user_id VISIBLE 秒级恢复，无感。
