必须交叉验证：查explain中key字段是否出现该索引，检查外键/唯一约束依赖，结合sys.schema_unused_indexes筛查，并将索引设为invisible后观察慢查询、handler_read指标及应用告警变化满24小时。
怎么确认一个索引真没被用，而不是“优化器懒得选”
只看 performance_schema.table_io_waits_summary_by_index_usage 的 COUNT_READ = 0 不够。这个视图统计的是运行时实际走索引的次数，但某些关键查询可能低频、偶发或被优化器跳过——比如 WHERE status IN ('pending', 'processing') 基数太高，EXPLAIN 显示没走索引，删了之后反而触发全表扫描。
实操建议：
- 先查该索引是否出现在核心 SQL 的
EXPLAIN FORMAT=TRADITIONAL的key字段里，尤其盯住 JOIN、ORDER BY、GROUP BY 和覆盖索引（Extra: Using index）场景 - 检查是否有外键或唯一约束隐式依赖它：主键、
UNIQUE索引即使COUNT_READ = 0也不能仅凭此删除 - 用
sys.schema_unused_indexes辅助筛查，但它依赖performance_schema数据，实例重启即清零，不能单独作为决策依据
ALTER TABLE ALTER INDEX INVISIBLE 执行后为什么 EXPLAIN 还不生效
执行 ALTER TABLE t ALTER INDEX idx_name INVISIBLE 后，EXPLAIN 依然看不到该索引是正常现象——不是失效，是优化器在解析阶段就把它从候选集中剔除了。你不会看到它“灰掉”，而是彻底不列出来。
验证是否生效必须分两步：
- 查元数据：
SELECT INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't' AND INDEX_NAME = 'idx_name';，值为NO才算成功 - 对比行为：普通查询
EXPLAIN SELECT * FROM t WHERE col = 1;应不走该索引；而强制使用EXPLAIN SELECT * FROM t USE INDEX (idx_name) WHERE col = 1;若报错ERROR 1176 (42000): Key 'idx_name' doesn't exist，说明索引名错了；若能走，则证明物理存在且可用
压测时怎么让不可见索引“临时现身”做真实对比
默认情况下，optimizer_switch='use_invisible_indexes=OFF'，所以不可见索引对优化器完全隐身。想对比“有/无该索引”的真实执行计划差异，必须手动打开开关。
推荐方式：
- 会话级启用（安全）：
SET SESSION optimizer_switch = 'use_invisible_indexes=on';，再跑EXPLAIN FORMAT=JSON，重点看used_indexes和key字段是否出现目标索引 - 单条 SQL 启用（更可控）：
SELECT /*+ SET_VAR(optimizer_switch = "use_invisible_indexes=on") */ * FROM t WHERE ... - 绝对不要用
FORCE INDEX (idx_name)—— 它会直接报错ERROR 1176，因为优化器逻辑上已注销该索引，不是“忽略”而是“不存在”
切换后观察什么信号才敢删索引
切为不可见只是第一步，真正决定是否删除，得看线上负载反应。单看一条 EXPLAIN 结果容易误判。
必须盯住的三个信号：
-
slow_query_log中Query_time或Rows_examined是否突增，特别是原来走该索引的高频接口 -
Handler_read_next/Handler_read_rnd_next是否明显上升——这是全表扫描或回表激增的硬指标 - 应用层告警：超时、重试、数据库连接池耗尽等间接信号，比 SQL 指标更早暴露问题
观察周期至少覆盖完整业务高峰，建议满 24 小时；备份恢复后需手动复查可见性，xtrabackup 不保留 INVISIBLE 属性，mysqldump 虽保留但低版本 MySQL 解析可能失败。
