MySQL 不可见索引怎么安全下线：验证查询影响再删除

订单后台准备清理一条长期没人认领的二级索引时，直接执行 DROP INDEX 往往太快了：报表、定时任务和少量带索引提示的 SQL 可能只在特定时段依赖它。MySQL 8.0 提供了一个更稳的中间步骤——先让索引对优化器不可见，观察真实查询，再决定恢复或删除。

把索引设为不可见不会立刻删除它，也不会停止写入维护；它主要用于模拟“没有这条索引”时的查询计划变化。只有经过业务时段复查、确认没有回归，才适合进入 DROP INDEX。

先确认这条索引到底负责什么

示例表是 orders，待评估索引名为 idx_orders_user_status_created，覆盖 user_id、status、created_at。先不要凭索引名猜用途，查看元数据和实际 SQL 访问范围。

SHOW INDEX FROM orders;

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

这里的 IS_VISIBLE 应为 YES，并且列顺序要和索引定义一致。还要从慢查询样本、代码仓库和定时任务中搜索 FORCE INDEX (idx_orders_user_status_created)；强制提示是不可见索引最容易暴露的兼容边界。

用不可见状态做一次可回滚的试验

确认没有正在进行的 DDL 后，执行下面的变更。它针对已有索引，不会把索引定义从表中抹掉。

ALTER TABLE orders
  ALTER INDEX idx_orders_user_status_created INVISIBLE;

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

再次查询结果时，目标索引的 IS_VISIBLE 应为 NO。这就是第一道可见成功状态：索引仍然存在，但普通优化器选路不会再把它当作候选。

用同一批查询比较 EXPLAIN 结果

不可见之后，不要只测试手工点开的订单列表。固定一批有代表性的 SQL，至少包括线上慢查询、后台列表、导出任务和最近修改过的查询。下面这条 SQL 的筛选条件正好对应示例索引：

EXPLAIN FORMAT=TREE
SELECT id, status, created_at
FROM orders
WHERE user_id = 10086
  AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

重点记录访问路径、估算行数和排序方式。不可见后如果从索引范围扫描变成全表扫描，或者出现明显的额外排序，不要急着判定“索引不能删”：先确认这条 SQL 是否覆盖真实高频路径，再把同一批查询在业务高峰和报表时段各跑一遍。

别把 EXPLAIN 的估算当成最终结论

EXPLAIN 描述的是优化器计划，不等于完整工作负载的实际耗时。把计划变化与慢查询样本、Performance Schema 中的摘要和数据库 CPU/IO 监控放在同一张复查记录里，才能看出偶发回归。

回归时立即恢复，稳定后再谈删除

如果订单列表、导出或定时任务出现可重复的延迟，先恢复可见性：

ALTER TABLE orders
  ALTER INDEX idx_orders_user_status_created VISIBLE;

恢复后再次执行同一批 EXPLAIN，确认访问路径回到预期状态，再观察一个完整业务周期。不可见索引仍会随着 INSERT、UPDATE 和 DELETE 被维护，因此试验期间不能把它当成“免费禁用”；写入开销和磁盘空间并没有立刻消失。

如果多个高峰时段都没有回归，再核对备份、变更窗口、回滚负责人以及是否存在索引提示。最终删除应使用明确的索引名：

ALTER TABLE orders
  DROP INDEX idx_orders_user_status_created;

删除之后恢复成本明显高于切换可见性，尤其是大表重建索引需要额外时间和空间。没有完成这组复查，就不要因为“当前没有慢查询告警”而直接删。

几个容易误判的边界

• 主键不能按普通二级索引的方式做这项试验；先区分索引类型。
• 带 FORCE INDEX 的查询可能直接报错，必须在变更前搜索并处理。
• 只验证一个接口不够，报表、导出和异步任务经常使用不同的时间范围。
• 不可见不等于不维护，写入压力没有因为优化器看不见它就自动下降。

相关问题

不可见索引会不会立刻释放磁盘空间？

不会。它仍保留在表结构中并继续维护，释放空间要等真正删除以及后续存储整理。

发现查询变慢时需要重新创建索引吗？

通常不需要，先执行 ALTER INDEX ... VISIBLE 恢复可见性即可；是否重建要另行判断。

可以用不可见索引测试强制索引提示吗？

不适合直接假设兼容。官方文档指出，引用不可见索引的索引提示可能报错，应把这类 SQL 单独列入变更前检查。

收尾检查清单

一次合格的索引下线评估，至少留下索引定义、候选 SQL、切换前后 EXPLAIN、业务时段观测、回滚命令和最终决策。能通过这六项记录，删除动作才有可追溯的依据；否则先保留索引，等下一次变更窗口继续验证。