MySQL invisible index 怎么验证索引删除前的影响

准备删除一个“看起来没被用到”的 MySQL 索引时，直接执行 DROP INDEX 不是最稳妥的验证方式。更安全的做法是先把二级索引改成 INVISIBLE：索引仍然存在并继续维护，但默认不再进入优化器的候选计划。然后分别运行默认的 EXPLAIN 和临时打开 use_invisible_indexes 的 EXPLAIN，对照 key、possible_keys 和 rows 的变化。

判断索引能不能删，至少要回答两个问题：隐藏它之后，线上查询计划是否恶化；让优化器重新看到它时，计划是否确实依赖它。invisible index 适合做这个低风险试运行，但最终决定仍要结合真实慢查询和业务流量。

先确认索引真的进入“不可见”状态

下面以订单表上的组合索引为例。先记录索引名和覆盖列，再把它隐藏。不要把主键当成普通二级索引处理：MySQL 不允许主键索引变成 invisible；某些没有显式主键的 InnoDB 表中，承担隐式主键作用的唯一索引也可能不能隐藏。

-- 只改变优化器可见性，暂不删除索引结构
ALTER TABLE orders
  ALTER INDEX idx_customer_created INVISIBLE;

-- 复核目标索引和可见性，不要只凭 ALTER TABLE 的返回信息判断
SELECT INDEX_NAME, COLUMN_NAME, SEQ_IN_INDEX, NON_UNIQUE, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
  AND INDEX_NAME = 'idx_customer_created'
ORDER BY SEQ_IN_INDEX;

也可以用 SHOW INDEX FROM orders 查看 Visible 列。这里要分清“索引还在”和“优化器默认会不会用”是两件事：隐藏后，写入数据仍会维护索引；如果它是唯一索引，唯一性约束也不会因为不可见而消失。

用 EXPLAIN 对比删除前后的优化器选择

索引隐藏后，先按线上原始 SQL 跑默认计划。重点看 key 是否从 idx_customer_created 变成另一个索引或 NULL，以及访问类型和估算行数是否明显变差。这个对比模拟的是“该索引不再被优化器考虑”，不是一次真实压测。

-- 默认情况下，invisible index 不进入优化器的候选集合
EXPLAIN SELECT order_id, created_at
FROM orders
WHERE customer_id = 42
  AND created_at >= '2026-01-01';

-- 只在本次计划构造中重新考虑 invisible index
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
       order_id, created_at
FROM orders
WHERE customer_id = 42
  AND created_at >= '2026-01-01';

对照结果时不要只盯着 key。可以把观察项记成一张小表：

如果两个计划完全一样，说明这条查询当前可能不依赖该索引，但不能推断所有查询都不依赖。应继续覆盖写入、列表、后台报表和高峰期常见条件；如果只在打开 use_invisible_indexes 后才出现更合适的计划，则它至少值得继续保留并观察。

把计划差异放回真实流量里判断

EXPLAIN 是成本模型的估算，不是线上执行结果。隐藏索引后，先观察受影响 SQL 的慢查询记录、性能模式统计和业务接口延迟；如果查询量有明显波动，再用与生产数据分布接近的环境做压测。还要留意统计信息变化，必要时在安全窗口执行 ANALYZE TABLE orders 后重新比较。

验证周期内发现回归，回滚只需要恢复可见性：

-- 发现查询计划或延迟回归时，先恢复优化器可见性
ALTER TABLE orders
  ALTER INDEX idx_customer_created VISIBLE;

-- 确认回滚后的元数据状态
SHOW INDEX FROM orders;

只有在隐藏期间覆盖了代表性查询、确认没有关键计划恶化，并且已经安排好重建成本和回滚窗口时，才考虑真正删除。删除前保留索引定义、列顺序、唯一性属性和线上观测结论，避免以后需要重建时只能凭记忆还原。

相关问题

invisible index 会停止写入维护吗？

不会。索引仍然存在，行变化仍会维护它；不可见主要影响优化器构造执行计划的候选范围。

为什么 EXPLAIN 里看不到隐藏索引？

这是默认行为。可以在单条 EXPLAIN 中通过 SET_VAR(optimizer_switch = 'use_invisible_indexes=on') 临时让优化器考虑它。

看不到索引就能直接 DROP 吗？

不能。至少要覆盖主要查询形态和高峰流量，并确认唯一约束、写入成本和回滚方案都没有被忽略。

官方语义可参考 MySQL 8.4 Invisible Indexes、SHOW INDEX 与 Optimizing Queries with EXPLAIN。