当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 不可见索引怎么验证删除索引的风险

MySQL 不可见索引怎么验证删除索引的风险

来源：17golang原创 2026-10-05 07:44:53 0浏览收藏

MySQL 不可见索引适合用来“模拟删除”，但它不是删除的同义词。把索引设为 INVISIBLE 后，优化器默认不再选它，索引结构仍保留，写入时也继续维护；如果查询变慢，可以先改回 VISIBLE，不必等待大表重新建索引。因此，验证删除风险的正确顺序是：记录基线、切换不可见、对比执行计划和真实负载，确认没有回退信号后再安排 DROP INDEX。

判断能不能删，至少要同时通过三关：索引确实不再被关键查询依赖、不可见期间没有新增慢查询或负载异常、业务约束没有被误判。只看一次 EXPLAIN 不够。

先确认索引与约束边界

先从数据字典确认目标索引，而不是凭索引名猜测。下面的查询可以看到字段、唯一性和可见状态；NON_UNIQUE=0 说明它承担唯一性约束，不能简单当作“多余索引”。

-- 先确认索引属性，避免把约束索引当成普通二级索引
SELECT INDEX_NAME, NON_UNIQUE, 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;

显式主键不能变为不可见；没有显式主键时，某些 NOT NULL 唯一索引还可能充当 InnoDB 的隐式主键，也不能直接隐藏。先确认表的主键、唯一索引、外键引用和关键查询，再选普通二级索引进入试验。

先把索引变为不可见，模拟删除而不破坏结构

假设目标是 idx_status_created，可以先执行：

-- 只改变优化器可见性，不删除索引文件或约束能力
ALTER TABLE shop.orders
  ALTER INDEX idx_status_created INVISIBLE;

-- 再确认状态，确保试验确实作用在目标索引上
SELECT INDEX_NAME, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop'
  AND TABLE_NAME = 'orders'
  AND INDEX_NAME = 'idx_status_created';

MySQL 不可见索引切换、优化器选择和唯一性约束的结构说明图 — 图1：不可见索引切换结构说明图，不是数据库客户端截图或运行证据。

这里的“删除模拟”只针对优化器选路。索引仍会随行数据变化而维护，唯一索引仍会阻止重复值，所以不可见化不会告诉你删除该约束是否安全。需要回退时执行：

-- 发现风险时快速恢复优化器选路
ALTER TABLE shop.orders
  ALTER INDEX idx_status_created VISIBLE;

用计划、慢日志和工作负载做三层对比

第一层是计划差异。对关键查询保存索引可见时的 EXPLAIN，切换不可见后再执行一次；重点看 key、type、rows 和 Extra。也可以临时让单条语句考虑不可见索引，帮助确认它原本是否有价值：

-- 用单条语句临时参考不可见索引，便于和默认计划对照
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
  order_id, created_at
FROM shop.orders
WHERE status = 'paid'
  AND created_at >= '2026-10-01';

第二层看真实工作负载：观察不可见期间是否出现新的慢查询、响应时间尾部变长或扫描行数增加。第三层再看 Performance Schema 中受影响语句的执行次数和耗时变化。低频报表可能不会马上出现在业务告警里，因此观察窗口应覆盖批处理、月末任务和主要读流量。