MySQL 不可见索引怎么用：删索引前先做可逆验证

删除 MySQL 索引最怕“删完才发现某个查询突然变慢”。不可见索引的价值就在这里：先把候选索引设为不可见，让优化器像没有这个索引一样选择访问路径；如果查询计划和线上指标都稳定，再考虑真正删除；如果发现影响，马上改回可见。

本文用一个订单表的索引清理场景，解释不可见索引解决了什么问题、和直接删除索引有什么区别、怎么验证效果，以及哪些限制必须提前知道。

背景：索引清理为什么容易犹豫

随着业务迭代，MySQL 表上经常会留下历史索引：旧接口不再使用，报表条件改了，或者多个联合索引之间出现重复前缀。索引越多，写入维护成本、磁盘占用和统计信息维护都会增加。

问题是，判断“这个索引真的没人用”并不简单。慢日志里没看到，不代表低频任务没有依赖；当前页面不走它，不代表月末报表、定时任务、后台导出不会走它。于是索引清理常常卡在一个尴尬状态：知道可能冗余，但不敢删。

假设订单表有这样一个索引：

CREATE TABLE orders (
  id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT UNSIGNED NOT NULL,
  status VARCHAR(16) NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  created_at DATETIME NOT NULL,
  KEY idx_user_id (user_id),
  KEY idx_status_created (status, created_at),
  KEY idx_amount (amount)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

其中 idx_status_created 看起来很久没被核心接口使用，但直接删除仍然有风险。不可见索引就是给这个灰度判断准备的工具。

旧做法问题：直接 DROP INDEX 的回滚成本

最直接的旧做法是删除索引：

ALTER TABLE orders DROP INDEX idx_status_created;

这条语句很干脆，但问题也很明显：如果删除后发现某个查询变慢，你需要重新建索引。大表重新建索引可能消耗较长时间，还会带来额外 IO 和变更风险。真正线上操作时，回滚并不是“再敲一条命令”那么轻松。

更稳的思路是先模拟“没有这个索引”的效果。不可见索引不会立刻删除索引结构，而是让优化器默认不把它当作可选路径。这样你能观察查询计划、慢日志和业务延迟变化，再决定下一步。

新规则：不可见索引只是让优化器先忽略

不可见索引不是一种新的索引结构。它的核心规则很简单：索引仍然存在，但优化器默认不会用它来生成查询计划。索引默认是可见的，你可以在建表、建索引或修改表时声明可见性，也可以把已有索引改成不可见或可见。

ALTER TABLE orders
  ALTER INDEX idx_status_created INVISIBLE;

ALTER TABLE orders
  ALTER INDEX idx_status_created VISIBLE;

索引状态可以用 SHOW INDEX 或 INFORMATION_SCHEMA.STATISTICS 查询：

SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

如果 IS_VISIBLE 变成 NO，说明这个索引已经对优化器不可见。接下来要看的是：原本可能使用它的 SQL 会不会换成更差的访问路径。

代码对比：从删除索引改成可逆验证

下面用一个典型查询做对比。业务按状态和时间查询最近订单：

EXPLAIN
SELECT id, user_id, amount, created_at
FROM orders
WHERE status = 'PAID'
  AND created_at >= '2026-07-01 00:00:00'
ORDER BY created_at DESC
LIMIT 50;

如果 idx_status_created 可见，计划里可能会看到它出现在 key 字段中。设为不可见之后，再执行同样的 EXPLAIN，就能看到优化器是否改用其他索引、扫描行数是否明显增加、是否出现额外排序。

ALTER TABLE orders
  ALTER INDEX idx_status_created INVISIBLE;

EXPLAIN
SELECT id, user_id, amount, created_at
FROM orders
WHERE status = 'PAID'
  AND created_at >= '2026-07-01 00:00:00'
ORDER BY created_at DESC
LIMIT 50;

观察时不要只看一条 SQL。建议把可能相关的查询都列出来：

• 后台列表页的筛选查询。
• 定时任务里按状态和时间扫描的查询。
• 导出报表或运营查询。
• 带索引提示的历史 SQL。

如果不可见之后计划明显变差，或者慢日志里出现以前没有的同类查询，就把索引改回可见：

ALTER TABLE orders
  ALTER INDEX idx_status_created VISIBLE;

这就是不可见索引比直接删除更适合灰度的地方：它让你先得到“删除后可能发生什么”的信号，再做破坏性动作。

兼容注意：写入仍维护，主键不能隐藏

不可见索引最容易被误解的一点是：它不是禁用索引，也不是让写入不再维护这个索引。只要索引还存在，插入、更新、删除相关列时仍然要维护索引结构；如果它是唯一索引，也仍然会约束重复值。

还有两个限制要提前记住：

• 主键索引不能设为不可见。
• 如果表没有显式主键，某些非空唯一索引可能承担类似主键的约束，也不能直接隐藏。

因此，不可见索引适合验证“查询是否还需要它”，不适合用来长期节省写入成本。如果观察期稳定，最终仍应清理真正冗余的索引。

采用建议：一套适合上线的观察清单

实际落地时，可以按下面这条流程走。

1. 先确定候选索引

候选索引通常来自三类线索：重复前缀、长期没有命中记录、和现有联合索引高度重叠。不要只因为名字看起来旧就处理，要先列出相关 SQL 和业务入口。

SHOW INDEX FROM orders;

2. 在低峰窗口设为不可见

选择一个低风险时间窗口，把候选索引改成不可见。变更后立即确认状态：

ALTER TABLE orders
  ALTER INDEX idx_status_created INVISIBLE;

SHOW INDEX FROM orders
WHERE Key_name = 'idx_status_created';

3. 观察查询计划和线上指标

至少观察这几类信号：

• EXPLAIN 里的 key、rows、Extra 是否明显变差。
• 慢查询日志是否新增同类 SQL。
• 接口 p95、p99 是否上升。
• 数据库 CPU、IO、临时表和排序相关指标是否异常。
• 是否有历史 SQL 使用索引提示并因此报错。

4. 保留快速恢复命令

发布单里应该提前写好恢复命令。如果业务指标异常，先恢复可见，再继续分析，不要在现场临时拼命令。

ALTER TABLE orders
  ALTER INDEX idx_status_created VISIBLE;

5. 稳定后再删除索引

如果观察期内查询计划、慢日志和业务指标都稳定，才进入真正删除阶段。删除前仍建议确认备份、变更窗口和回滚方案。

ALTER TABLE orders
  DROP INDEX idx_status_created;

总结

MySQL 不可见索引的核心不是“让索引消失”，而是给索引清理提供一个可逆验证步骤。先把候选索引设为不可见，用 EXPLAIN、慢查询日志和业务指标观察影响；如果异常，改回可见；如果稳定，再安排真正删除。它能降低删索引的决策风险，但不能替代最终清理，也不能减少仍然存在的索引维护成本。

参考资料

• MySQL 8.4 Reference Manual：Invisible Indexes