MySQL invisible index 试验结束后如何恢复可见

MySQL invisible index 试验结束后，不需要删除再重建索引。只要确认目标表和索引名，执行 ALTER TABLE 表名 ALTER INDEX 索引名 VISIBLE;，索引就会恢复为可见状态，重新进入优化器的候选范围。恢复后还要查一次元数据，再用代表性查询运行 EXPLAIN；前者证明属性改对了，后者才说明这条查询有机会重新考虑该索引。

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

先确认目标索引和当前状态

我通常先把库名、表名和索引名写进检查清单，再执行状态查询。这样可以避免在同名表或错误 schema 上完成“成功”的恢复。

-- 读取目标表中每个索引的可见性，先确认库名和表名
SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
GROUP BY INDEX_NAME, IS_VISIBLE;

-- 也可以从 SHOW INDEX 的 Visible 列交叉确认
SHOW INDEX FROM shop.orders;

目标索引若显示 NO 或 Visible=NO，才需要执行恢复。主键不能设置为 invisible；某些承担隐式主键作用的唯一索引也可能不能切换，这类错误不是索引名写错，而是 MySQL 的约束边界。

恢复可见只需要切换索引属性

确认对象后，使用 ALTER TABLE ... ALTER INDEX 修改现有索引属性：

-- 只恢复可见性，不删除索引定义和索引数据
ALTER TABLE shop.orders
  ALTER INDEX idx_orders_user_created VISIBLE;

这一步的重点是保留原索引。invisible 只表示优化器默认不把它作为普通候选，索引仍会随表数据变化而维护，唯一索引的唯一性约束也不会因为 invisible 而消失。因此，恢复可见不是“重新创建一份索引”，也不应顺手改列顺序、前缀长度或索引名。

用元数据和 EXPLAIN 做双重确认

语句返回成功只说明 ALTER 操作被接受，收尾时还要检查状态：

-- 元数据层确认：目标索引应返回 YES
SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND INDEX_NAME = 'idx_orders_user_created';

-- 计划层确认：只观察这条代表性查询的候选与实际选择
EXPLAIN SELECT order_id, created_at
FROM shop.orders
WHERE user_id = 10086
ORDER BY created_at DESC;

IS_VISIBLE=YES 说明属性恢复了；EXPLAIN 中的 possible_keys 可能重新出现该索引，key 则表示本次计划实际选择的索引。若 visible 已是 YES 而 key 仍为空，先不要反复执行 ALTER：数据量、统计信息、过滤条件、排序代价和其他索引都可能让优化器选择别的方案。

上线收尾时保留这张检查清单

如果试验结论仍不确定，可以再次把同一个索引切回 INVISIBLE 做对照，但要记录每次切换时间和代表性 SQL。不要用“visible 后 EXPLAIN 没选中”推断索引无效，也不要用一次计划变化替代线上延迟和慢查询观察。

常见问题

恢复可见后一定会被使用吗？

不一定。VISIBLE 只把索引放回优化器可考虑的范围，最终仍由成本估算和查询条件决定。

恢复可见需要重建索引吗？

通常不需要。恢复的是 visibility 属性，不是索引定义；除非另有索引损坏或定义变更需求。

为什么 ALTER INDEX 报主键不能 invisible？

主键以及承担隐式主键作用的某些唯一索引受 MySQL 约束保护，不能按普通二级索引切换可见性。