登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  MySQL

不可见索引 怎样做安全回滚试验

来源:17golang原创

时间:2026-10-25 10:51:39 254浏览 收藏

如果你想判断一个二级索引是否已经可以删除,先不要直接执行 DROP INDEX。MySQL 的不可见索引可以把索引从普通优化器候选中暂时拿开,再观察执行计划和线上工作负载;证据显示有回归时,用 ALTER INDEX ... VISIBLE 恢复。这个试验改变的是优化器是否考虑索引,不等于删除索引。

官方地址:https://dev.mysql.com/doc/refman/8.4/en/

安全回滚的关键是先确认对象是可隐藏的普通二级索引,再把“计划变化”和“真实负载变化”分开观察。不可见期间索引仍会维护,唯一索引仍然承担唯一性约束,因此它适合做影响试验,不是通用的删除替代品。

先确认索引能否进入试验

普通二级索引是最适合的候选。主键不能设为不可见;某些没有显式主键的 InnoDB 表中,定义在非空列上的唯一索引可能承担隐式主键职责,也不能直接隐藏。先把索引名称、列顺序和可见性记录下来,再决定是否继续。

-- 先记录目标表的索引名称、列顺序和可见性
SELECT INDEX_NAME, SEQ_IN_INDEX, COLUMN_NAME, NON_UNIQUE, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'app_db'
  AND TABLE_NAME = 'orders'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

-- 也可以用 SHOW INDEX 快速查看当前状态
SHOW INDEX FROM app_db.orders;

这里的 IS_VISIBLE 是试验前的基线。若目标是主键、隐式主键,或者唯一性约束本身不能被破坏,就不要为了“测试删除”强行改状态。

二级索引、主键、隐式主键与 IS_VISIBLE 和唯一性约束的静态关系说明图
图1:不可见索引的对象边界说明图,不是截图或运行证据。

把候选二级索引设为不可见

确认对象后,可以使用 ALTER TABLE ... ALTER INDEX 切换可见性。下面的语句只针对普通二级索引;执行前应把索引名替换成已经核对过的目标。

-- 让优化器默认忽略候选索引,但保留索引本身
ALTER TABLE app_db.orders
  ALTER INDEX idx_orders_customer INVISIBLE;

-- 试验结束后恢复普通优化器可见性
ALTER TABLE app_db.orders
  ALTER INDEX idx_orders_customer VISIBLE;

不可见不代表停止维护:行数据发生变化时,该索引仍会更新;如果它是唯一索引,重复值约束也仍然存在。也就是说,这一步主要隔离的是优化器选型影响,写入成本和存储占用不会因为隐藏就自动消失。

比较计划和真实工作负载

状态切换后不要只看一条 EXPLAIN。先选择覆盖该索引典型访问方式的查询,比较不可见前后的访问类型、候选索引和预估行数,再结合慢查询日志与 Performance Schema 观察实际工作负载是否出现回归。

-- 用同一条代表性查询观察不可见后的计划变化
EXPLAIN SELECT order_id, created_at
FROM app_db.orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

-- 需要做对照时,只在当前语句临时允许优化器考虑不可见索引
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
       order_id, created_at
FROM app_db.orders
WHERE customer_id = 10086
ORDER BY created_at DESC
LIMIT 20;

第二条语句是对照工具,不是把全局开关永久打开。默认情况下,use_invisible_indexes 为关闭;通过语句级提示可以临时构造“如果索引仍可选,计划会怎样”的比较。真实请求是否变慢,还要看慢查询日志、Performance Schema 里的语句统计以及业务时段的负载变化。

不可见索引、优化器计划、EXPLAIN、慢查询日志、Performance Schema 与 VISIBLE 回滚的静态关系图
图2:计划与工作负载观测关系图,不是截图或运行证据。

按证据决定恢复还是继续观察

可以把结果分成三种情况:如果核心查询出现明显计划退化或慢查询增加,立即执行 VISIBLE 回滚;如果计划变化但业务指标稳定,继续覆盖更多查询类型和时段;如果长期没有回归,也只能说明“暂时未观察到依赖”,不能直接证明可以删除。

观察结果处理建议
核心查询变慢或错误恢复可见,记录受影响语句
只有计划改变扩大样本,不用单条 EXPLAIN 定案
多时段均无回归再评估维护成本和存储成本

最后要记住:不可见索引让“删除前试验”可回退,但它没有减少索引维护,也没有绕过主键和唯一性边界。真正删除前,仍应保留回滚窗口、记录观察范围,并把恢复语句放进变更单。

相关问题

不可见索引会不会停止写入维护?

不会。索引仍会随行变更维护,因此隐藏状态不能直接当成降低写入成本的方案。

为什么主键不能设为不可见?

主键是表的核心访问与约束结构;某些唯一非空索引还可能承担隐式主键职责,所以也可能不能隐藏。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>