MySQL 8.0隐藏索引 Invisible Index实战：安全验证索引效果的零风险方案

为什么要使用隐藏索引而不是直接删除

MySQL DBA在优化慢查询时经常面临一个决策：某个索引长期未被使用，占用了大量磁盘空间还拖慢写入性能，但直接删除又担心影响未知查询。一旦删错索引导致业务SQL性能劣化，恢复的代价很大——大表上重建索引可能锁表数小时。

MySQL 8.0引入的Invisible Index（隐藏索引）解决了这个问题。将索引设为不可见后，优化器不会选择该索引，但索引数据仍然在磁盘上维护。这意味着可以零风险验证索引删除的影响：如果业务正常，确认删除；如果出现慢查询，一条ALTER语句瞬间恢复。

Invisible Index的工作机制与操作方法

隐藏索引的核心原理是：MySQL优化器在生成执行计划时会跳过invisible属性的索引，但InnoDB引擎层仍然正常维护索引的B+Tree结构。DML操作（INSERT、UPDATE、DELETE）对隐藏索引的维护开销与可见索引完全相同。

基本操作：

-- 创建隐藏索引
ALTER TABLE orders
  ADD INDEX idx_create_time
  (create_time) INVISIBLE;

-- 将现有索引设为隐藏
ALTER TABLE orders
  ALTER INDEX idx_status INVISIBLE;

-- 恢复为可见
ALTER TABLE orders
  ALTER INDEX idx_status VISIBLE;

-- 查看索引的可见性状态
SELECT index_name, is_visible,
       column_name
FROM information_schema.statistics
WHERE table_schema = 'your_db'
  AND table_name = 'orders'
ORDER BY index_name, seq_in_index;

使用sys.schema_unused_indexes定位候选索引

在将索引设为隐藏之前，先用sys库确认哪些索引确实未被使用：

SELECT object_schema, object_name,
       index_name
FROM sys.schema_unused_indexes
WHERE object_schema NOT IN
  ('mysql','sys',
   'performance_schema',
   'information_schema')
ORDER BY object_schema, object_name;

需要注意，sys.schema_unused_indexes的数据源自performance_schema.table_io_waits_summary_by_index_usage，其统计信息在MySQL重启后会清零。因此至少等MySQL运行一周以上再参考此数据，避免误判。

更严谨的做法是结合慢查询日志和Performance Schema做交叉验证：

SELECT object_schema AS db,
       object_name AS tbl,
       index_name,
       count_read,
       count_write,
       count_read + count_write
         AS total_access
FROM performance_schema
  .table_io_waits_summary_by_index_usage
WHERE object_schema = 'your_db'
  AND index_name IS NOT NULL
  AND index_name != 'PRIMARY'
ORDER BY total_access ASC;

隐藏索引验证流程与回滚方案

生产环境的安全验证流程分为四步：

第一步：标记索引为隐藏。在业务低峰期执行，避免ALTER期间的MDL锁与长事务冲突。

ALTER TABLE orders
  ALTER INDEX idx_redundant INVISIBLE;

第二步：观察期。隐藏索引后持续观察7-14天，监控慢查询日志和全表扫描事件。

第三步：确认删除或恢复。如果观察期内没有出现新的慢查询或全表扫描，安全删除索引；如果出现性能劣化，立即恢复：

-- 确认删除
ALTER TABLE orders
  DROP INDEX idx_redundant;

-- 出现问题立即恢复（毫秒级操作）
ALTER TABLE orders
  ALTER INDEX idx_redundant VISIBLE;

第四步：特殊场景。如果某个会话需要临时使用隐藏索引调试，可以修改会话级优化器开关：

SET SESSION optimizer_switch =
  'use_invisible_indexes=on';

EXPLAIN SELECT * FROM orders
WHERE create_time > '2026-01-01';

SET SESSION optimizer_switch =
  'use_invisible_indexes=off';

隐藏索引的局限与注意事项

1. 隐藏索引仍然占用磁盘和写入开销。Invisible不是禁用维护，索引的B+Tree结构仍然在每次DML时更新。如果目标是减少写入开销，隐藏索引无法达成，必须真正删除。

2. 主键和唯一索引不能设为隐藏。InnoDB的主键是聚簇索引，唯一索引用于约束检查，这两类索引不支持INVISIBLE属性。

3. 复制环境的一致性。主库设为隐藏的索引，从库也是隐藏的。如果只在主库执行ALTER INDEX VISIBLE，不会自动同步到从库，需要确保主从配置一致。

4. performance_schema统计的隐藏索引访问。隐藏索引被优化器忽略后，count_read将为0，但count_write不为0（DML仍维护索引）。这可能导致schema_unused_indexes误判，需要结合EXPLAIN分析确认。

隐藏索引是MySQL 8.0给DBA提供的安全网，让索引优化从删了后悔变成试了再定。但它的安全是有边界的——写入开销不会减少，磁盘占用不会释放。在验证完成后及时真正删除无用索引，才能获得完整的优化收益。