MySQL 8.4 隐藏索引怎么试：不删索引也能验证查询计划

线上发现一个二级索引很久没有命中，最危险的做法是直接执行 DROP INDEX。MySQL 8.4 提供了更稳妥的观察窗口：先把索引改成 INVISIBLE，让优化器默认忽略它，再用 EXPLAIN 对照查询计划；如果只想验证一条查询，还可以通过 use_invisible_indexes=on 临时把它纳入计划评估。

先把“没命中”拆成一个可验证的问题

索引长期没有出现在慢查询记录里，并不能单独证明它可以删除。查询可能被覆盖索引、条件选择性、统计信息，或者一次性业务流量影响。本文只围绕一个边界：候选索引 idx_customer_status 是否仍会改变 orders 表上某类查询的计划。图里的 customer_id + status 表示这条查询的联合过滤条件，最终要对照的是 EXPLAIN 查询计划。

先记录同一条代表性查询的 SQL、业务时间范围和当前计划。不要一边改索引一边改 WHERE 条件，否则前后结果无法归因。

EXPLAIN SELECT order_id, status
FROM orders
WHERE customer_id = 10086 AND status = 'PAID';

EXPLAIN展示的是优化器打算怎样处理语句；它不是线上耗时证明。需要核对实际执行时，MySQL 8.4 的 EXPLAIN ANALYZE会运行语句，因此要在可控窗口、只读事务或脱离生产流量的环境使用。

先确认索引状态，再做隐藏观察

隐藏前先从元数据确认索引名和可见性，避免把同名索引、主键或唯一约束误当成普通二级索引。MySQL 官方文档说明，主键不适用这套隐藏规则；普通二级索引可以通过 ALTER TABLE ... ALTER INDEX 在可见与不可见之间切换。

SHOW INDEX FROM orders;

ALTER TABLE orders
  ALTER INDEX idx_customer_status INVISIBLE;

SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders';

这里的重点不是记住某个输出数字，而是确认 idx_customer_status 的可见性已经变成 NO。隐藏索引仍然占用存储空间，也仍会随写入维护，所以它适合短期验证，不适合长期代替索引治理。

用相同查询比较隐藏前后的计划

隐藏完成后重新执行完全相同的 EXPLAIN。如果计划从索引查找变成全表扫描，或者访问路径、估算行数明显变化，说明该索引确实参与过优化器决策；这时不要急着删除，应继续核对受影响的查询集合。

只想验证一条 SQL 时，用查询级开关

如果索引已经隐藏，但你想确认“这条 SQL 原本是否会选择它”，可以在 EXPLAIN 中使用 SET_VAR hint：

EXPLAIN
SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
       order_id, status
FROM orders
WHERE customer_id = 10086 AND status = 'PAID';

这个开关只改变该条语句的计划构造，让不可见索引留在候选集合中；它不会把索引恢复成全局可见。把它与隐藏后的普通 EXPLAIN并排保存，就能区分“索引本身有效”和“全局优化器当前应该选它”这两个问题。

恢复、删除与复盘不要混成一个动作

验证期间发现关键查询明显退化，先恢复索引可见性：

ALTER TABLE orders
  ALTER INDEX idx_customer_status VISIBLE;

恢复后再次检查 SHOW INDEX 和代表性 EXPLAIN。如果计划恢复，还要在慢查询、写入延迟和存储空间之间做一次复盘。确认索引确实冗余后，删除是单独的变更评审；不要把“隐藏期间没看到报警”当作全量无风险证明。

常见问题

隐藏索引是不是等于删除索引？

不是。隐藏索引仍存在并继续维护，优化器默认不使用它；删除才会释放索引结构和相关维护成本。

为什么隐藏后 EXPLAIN 还可能看到类似的访问路径？

优化器可能选择了另一个索引，或者统计信息和查询条件使两条路径表现接近。应同时看 key、估算行数和实际业务耗时。

use_invisible_indexes=on 会让索引全局恢复吗？

不会。它只对带有该 hint 的语句影响计划评估，索引在元数据中的状态仍是 Invisible。

隐藏索引观察多久再删除？

没有通用固定天数。至少应覆盖真实业务的高峰、批处理和关键报表，并结合慢查询、写入开销与变更回滚能力评估。

把隐藏索引当作一个可逆观察状态，验证的是“删掉它会改变什么”，而不是提前宣告“它一定没用”。对于 MySQL 8.4 的索引治理，这个边界通常比一次性删除更值得保留。