当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 8.0 隐形索引如何做上线前验证：不改 SQL 对比优化器选型

MySQL 8.0 隐形索引如何做上线前验证：不改 SQL 对比优化器选型

来源：17golang原创 2026-08-28 00:48:23 0浏览收藏

线上订单查询突然变慢时，直接删掉“看起来没用”的索引往往太冒险：它可能只服务一条低频报表 SQL，也可能被某个高峰时段的请求依赖。MySQL 8.0 的隐形索引提供了一个更稳的验证办法——先让优化器暂时看不见索引，保持索引结构和数据维护不变，再用同一条 SQL 对照查询计划，最后决定恢复还是下线。

隐形索引适合做“先观察、后删除”的灰度验证：把目标二级索引设为 INVISIBLE，检查 EXPLAIN 与实际耗时；确认业务没有回归后，再安排正式删除。

要点速览

验证对象是二级索引，不把主键当成可隐藏对象。
默认关闭 use_invisible_indexes 后，优化器会忽略隐形索引。
同一条 SQL 要同时比较 EXPLAIN、耗时和慢查询变化。
发现回归时执行 ALTER INDEX ... VISIBLE 即可快速恢复。

先把“索引没用”变成可验证的问题

假设订单表有一个组合索引 idx_user_created，最近一次索引盘点发现它的使用记录很少。盘点结果只能说明“平时不常用”，不能证明删除安全，因为统计窗口、报表时间和故障流量都可能遗漏。

这次小实验只回答一个问题：当优化器暂时看不到 idx_user_created 时，订单列表查询的计划和响应是否明显变差。数据、SQL 文本和连接参数都保持不变，避免把其他变量混进结论。

准备一条可重复的订单查询

在测试库准备与线上结构接近的 orders 表，并先确认索引名称。不要凭记忆改索引，先读取元数据：

SHOW INDEX FROM orders;

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

记录目标 SQL 的基线计划和耗时。示例查询固定用户、时间范围和排序方式，测试前后不要临时换条件：

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

用隐形索引做一次计划对照

先将目标索引设为隐形。这个动作不会删除索引页，写入时索引仍会被维护；变化点是默认优化器不再把它作为候选访问路径。

ALTER TABLE orders
  ALTER INDEX idx_user_created INVISIBLE;

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

结果里 IS_VISIBLE 应为 NO。现在重新执行同一条 EXPLAIN，重点看 key、rows 和 Extra 是否发生变化。如果计划切换到全表扫描或扫描行数明显增加，说明这个索引仍有价值。

还可以在单个会话里打开 use_invisible_indexes，把隐形索引重新放回候选集合，验证它是否仍是更好的计划：

SET SESSION optimizer_switch = 'use_invisible_indexes=on';

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

这里的对照只用于分析，不要把会话变量当成全局修复。把“默认不可见”和“临时可见”的两份计划保存下来，后续更容易和慢查询记录对齐。

把计划变化和真实耗时放在一起验收

EXPLAIN 是估算，不是实际运行结果。对低风险测试数据，可以用 EXPLAIN ANALYZE 观察实际行数和耗时；生产流量则应结合 Performance Schema、慢查询日志和应用侧 P95，而不是只看一条手工请求。

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

验收至少留三份证据：目标 SQL 在可见索引状态下的计划、隐形状态下的计划，以及固定样本下的耗时分布。若只是偶发抖动，先扩大样本和时间窗口；若扫描行数与延迟一起稳定上升，不要急着删除。

发现回归时如何恢复

只要目标索引还没有被删除，恢复动作很直接：

ALTER TABLE orders
  ALTER INDEX idx_user_created VISIBLE;

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

再次看到 IS_VISIBLE = YES 后，重新核对目标 SQL 的计划。若线上已经出现慢查询，恢复索引后还要确认延迟回落；别把“元数据恢复成功”误当成“业务已经恢复”。