Invisible Index 灰度验证怎么配置或排查

想验证一个 MySQL 二级索引是否还值得保留，不必先执行 DROP INDEX。更稳妥的做法是先把它设为 Invisible：默认优化器会忽略它，但索引结构仍在；需要对照时，再在单独会话里打开 use_invisible_indexes。这样可以把“没有这个索引时会怎样”和“这个索引本身能提供什么”拆开观察，出现回归也能快速恢复。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/invisible-indexes.html

确认候选索引与基线

灰度验证的第一步不是改表，而是锁定一个具体查询和一个具体索引。例如订单表上的 idx_user_status 可能服务于“按用户和状态筛选”的查询，也可能只是历史遗留。先确认列顺序、索引类型和当前可见性，再保存同一查询的计划与观测值。

-- 读取索引可见性，避免把目标索引名写错
SELECT INDEX_NAME, COLUMN_NAME, SEQ_IN_INDEX, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

-- 用固定条件保存基线计划；实际业务值应替换为脱敏样例
EXPLAIN SELECT order_id
FROM shop.orders
WHERE user_id = 1001 AND status = 'paid';

记录时至少保留 key、rows、访问类型和查询延迟。这里的基线要固定 SQL 形状、参数范围和数据时间段，否则后面的差异可能来自条件变化，而不是索引可见性。

让索引退出默认优化计划

确认目标后，把二级索引设为不可见。语句针对的是索引名，不是列名；主键不能用这种方式隐藏。执行前确认连接指向测试或灰度环境，并把回滚语句一并写进变更单。

-- 让优化器在默认会话中暂时忽略候选二级索引
ALTER TABLE shop.orders
  ALTER INDEX idx_user_status INVISIBLE;

-- 出现计划或延迟回归时，快速恢复默认可见性
ALTER TABLE shop.orders
  ALTER INDEX idx_user_status VISIBLE;

设为 Invisible 后，索引并没有消失，写入仍需维护它，空间也不会立即释放。它的价值在于先模拟“优化器看不见它”的状态，避免删除后再重建的大成本。

用会话级开关做灰度对照

默认情况下，优化器不把 Invisible Index 纳入计划构造。若想单独验证“候选索引能否改善这条查询”，不要修改全局配置，优先在一个验证会话或一条 EXPLAIN 上临时打开开关。

-- 只在当前验证连接中重新考虑 Invisible Index
SET SESSION optimizer_switch = 'use_invisible_indexes=on';

-- 只影响这一条 EXPLAIN，适合和默认计划并排保存
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */ order_id
FROM shop.orders
WHERE user_id = 1001 AND status = 'paid';

对照时至少保存三份信息：索引可见时的基线计划、不可见后的默认计划、不可见但开启开关后的候选计划。第三份只能说明该索引仍可被优化器考虑，不代表线上一定更快；真实结论还要看业务参数和并发。

按证据决定恢复或继续清理

可以用一张小表记录同一查询在相同时间窗口的观测，避免只盯着一次 EXPLAIN：

一旦出现慢查询增加、计划转为更大范围扫描，或者带索引提示的查询报错，就先执行 VISIBLE 回滚，再分析具体 SQL。只有在代表性查询、写入开销和运维依赖都确认后，才安排独立窗口评估 DROP INDEX；Invisible Index 本身不是删除确认。

常见问题

Invisible Index 会停止写入维护吗？

不会。它仍是表上的索引，主要变化是默认优化器不使用它；因此写入维护成本和占用空间仍需计入评估。

为什么设为 Invisible 后 EXPLAIN 不再选它？

因为默认的 use_invisible_indexes 是关闭的。验证单条查询时，可使用 SET_VAR 临时打开，而不是改全局开关。

验证结果稳定就能马上 DROP INDEX 吗？

不能只凭一次计划下结论。还要检查索引提示、定时任务、报表和不同参数分布；出现不确定性时保留 Invisible 状态并继续收集证据。