MySQL 不可见索引灰度验证：先观察优化器，再安全下线旧索引

线上订单列表突然多出一百多毫秒，第一反应通常是“这个索引是不是该删了”。但直接删除很难回头，尤其是报表、后台筛选和夜间任务共用一张表时。MySQL 8.0 的不可见索引提供了一个更稳的中间步骤：先让优化器暂时看不见索引，观察真实查询计划和延迟，确认没有回退，再决定是否删除。

不可见索引解决的不是“建不建”，而是“敢不敢下线”

假设 orders 表上有一个历史索引：

KEY idx_orders_user_status_created (user_id, status, created_at)

最近的访问模式已经变成按 tenant_id + created_at 查询，团队想清理旧索引来减少写入开销。问题在于，索引使用情况往往不是白天接口这一条链路，导出脚本、客服筛选和补偿任务都可能依赖它。

不可见索引的价值，是把“删除”拆成两个可验证动作：先改变优化器的选择，再保留索引结构作为快速恢复点。它不会停止索引维护，所以写入成本不会立刻消失；这正是它适合灰度、却不能长期替代索引治理的原因。

先确认版本和候选索引，不要凭名字判断使用情况

先确认服务端版本，并把候选索引的列顺序记录下来：

SELECT VERSION();

SHOW INDEX FROM orders;

SELECT TABLE_NAME, INDEX_NAME, IS_VISIBLE, CARDINALITY
FROM information_schema.statistics
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders';

SHOW INDEX 适合快速看结构，information_schema.statistics 更适合写成巡检脚本。这里重点看三件事：索引是否真的存在、是否已经不可见、列顺序是否覆盖了目标查询的过滤和排序。不要只看索引名里有没有 status，要结合实际 SQL 的谓词顺序判断。

用不可见状态做一次可回退的执行计划对比

下面的操作只改变优化器是否考虑索引，不会删除索引：

ALTER TABLE orders
  ALTER INDEX idx_orders_user_status_created INVISIBLE;

改完后，针对接口和后台任务中最常见的 SQL 分别执行 EXPLAIN。建议把关键列保存下来比较：key、rows、filtered、Extra，如果版本支持，也可以用 EXPLAIN ANALYZE 对测试流量做一次实际耗时核对。

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

如果 key 变成了更适合当前查询的索引，且线上 P95、扫描行数和慢查询没有恶化，可以继续观察。若计划退化为全表扫描或回到一个明显更宽的索引，不要急着删，先恢复可见性再分析。

只给需要恢复的会话打开不可见索引

不可见索引默认不参加选路，但 MySQL 提供了会话级开关，方便验证某条历史 SQL 是否仍依赖它：

SET SESSION optimizer_switch = 'use_invisible_indexes=on';

EXPLAIN SELECT id
FROM orders
WHERE user_id = 901 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 50;

SET SESSION optimizer_switch = 'use_invisible_indexes=off';

这个开关只影响当前连接。连接池场景要特别小心：如果在调试连接里打开后没有恢复，后续复用该连接的请求可能继续看到不可见索引。更稳的做法是把它放进一次性诊断脚本，并在脚本结束时显式关闭。

什么时候可以从不可见走到删除

不可见状态至少要跨过一个完整业务周期，覆盖高峰接口、定时任务和月末类查询。判断时不要只看一次 EXPLAIN，可以按下面的边界检查：

确认可以删除后，再执行：

ALTER TABLE orders
  DROP INDEX idx_orders_user_status_created;

删除前最好留出低峰窗口，并保存删除前后的 SHOW CREATE TABLE orders、关键 SQL 的执行计划和监控截图。这样即使后来发现夜间任务受影响，也能明确是哪个变更造成的，而不是在一堆索引调整里凭感觉回滚。

相关问题：不可见索引灰度的三个边界

不可见索引会不会降低写入开销？

不会立刻降低。索引仍然随着 INSERT、UPDATE、DELETE 维护，所以它更像“优化器灰度开关”，不是节省存储和写放大的最终动作。

不可见索引和禁用索引是一回事吗？

不是。不可见索引仍然存在并可被特定会话使用；禁用索引是另一种状态，适用范围和行为不同，不能拿一条语句直接互换。

改成不可见后能不能马上删除？

不建议。至少要覆盖真实高峰、异步任务和回滚验证；如果没有可观测的计划与延迟数据，不可见只是把风险推迟了。

把索引下线变成一个有证据的变更

对于不确定是否仍被使用的旧索引，先不可见、再观察、最后删除，比直接执行 DROP INDEX 多了一层保护。实际操作中，最小闭环就是保存变更前计划、切换不可见、观察关键 SQL 和指标、必要时会话级恢复，最后才处理物理删除。索引治理真正需要的不是更激进的清理速度，而是每一步都能说清楚“谁受影响、怎么验证、如何退回”。