MySQL 怎么用不可见索引测试删除影响

不可见索引适合做“删除前演练”：先把候选索引改为 INVISIBLE，让优化器默认忽略它，再比较代表性 SQL 的执行计划和业务指标。确认没有负面影响后再安排删除；一旦发现回退或慢查询，立即改回 VISIBLE。整个测试期间索引仍会随写入维护，唯一性约束也仍然生效。

先确认哪些索引可以参与测试

不可见索引不能替代备份，也不是“暂停维护索引”。它只是改变优化器是否把该索引纳入普通计划选择。主键不能设为不可见；没有显式主键时，首个满足条件的 UNIQUE NOT NULL 索引可能承担隐式主键作用，也不能直接隐藏。

-- 先查看候选索引及其可见状态，避免误操作主键
SHOW INDEX FROM orders;

-- 也可以只查询需要审查的字段
SELECT INDEX_NAME, NON_UNIQUE, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders';

把候选索引、关联 SQL、当前 EXPLAIN 结果和观察窗口记录下来。不要一次隐藏多个索引，否则计划变化后很难判断是哪一个索引造成影响。

隐藏索引并比较执行计划

先保存基线，再修改可见性。对大表而言，切换可见性通常比删除后重建更容易回退，但仍应在变更窗口内执行，并观察应用中真正重要的查询。

-- 记录索引仍可见时的基线计划
EXPLAIN SELECT id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

-- 让优化器默认忽略候选索引
ALTER TABLE orders ALTER INDEX idx_customer_created INVISIBLE;

-- 再次取得计划，重点比较 key、type、rows 和 Extra
EXPLAIN SELECT id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

如果 key 变为其他索引或 NULL，同时估算扫描行数明显增加，说明这个索引仍可能有价值。还要观察慢查询日志与 Performance Schema 中相关语句的负载变化，不能只凭一条手工 SQL 下结论。

用单条查询做反向对照

索引保持不可见时，可以在一条查询中临时打开 use_invisible_indexes，查看优化器重新考虑该索引后的计划。这样能形成“默认忽略”和“临时启用”的对照，而不必先改回全局可见。

-- 只对当前 EXPLAIN 临时允许使用不可见索引
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
       id, customer_id, created_at
FROM orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

如果临时启用后重新选中 idx_customer_created，而默认计划明显更差，这就是保留或重做索引设计的强信号。若两边计划和实际工作负载都稳定，再继续扩大观察范围。

决定恢复还是进入正式下线

-- 发现风险时快速恢复候选索引的可见性
ALTER TABLE orders ALTER INDEX idx_customer_created VISIBLE;

注意：不可见索引仍占用存储并承担写入维护成本，因此不能长期把大量废弃索引留在不可见状态。它更适合作为有期限的验证手段。

常见问题

不可见索引还能保证唯一性吗？

可以。索引不可见不等于索引失效，唯一索引仍会阻止重复值写入。

为什么修改索引可见性时报主键不能隐藏？

主键不能设为不可见；没有显式主键时，某个 UNIQUE NOT NULL 索引还可能被当作隐式主键。先确认表的主键结构，再选择普通二级索引测试。