MySQL 隐形索引评估删除风险的方法

删除一个“看起来没用”的 MySQL 索引，风险不在于 DROP INDEX 语句本身，而在于你是否真的覆盖了低频查询、报表和索引提示。更稳妥的做法是先把目标二级索引设为隐形，让优化器暂时忽略它，再比较关键 SQL 的执行计划和慢查询变化；确认没有回归后才安排删除，发现问题则恢复可见，回滚成本很低。

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

隐形索引不是删除：索引结构仍在、写入维护仍在，只是默认不参与优化器的计划选择。评估时要同时看索引状态、EXPLAIN、真实慢查询和回滚窗口。

先确认索引状态，再做可逆切换

先列出目标表的索引，确认名称、字段顺序和 Visible 状态。MySQL 8.4 也可以从 INFORMATION_SCHEMA.STATISTICS 读取 IS_VISIBLE。不要直接拿 PRIMARY KEY 做实验；主键以及某些承担隐式主键作用的唯一索引不能设为隐形。

-- 先确认索引对象与可见性，避免把主键误当成普通二级索引
SHOW INDEX FROM orders;

-- 用系统表核对目标索引，字段名和索引名按实际表结构替换
SELECT INDEX_NAME, COLUMN_NAME, NON_UNIQUE, IS_VISIBLE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'shop' AND TABLE_NAME = 'orders';

-- 只对确认过的二级索引做可逆切换
ALTER TABLE orders ALTER INDEX idx_orders_customer INVISIBLE;

切换完成后，用同一条查询再次执行 EXPLAIN，不要把“索引还存在”误解成“优化器还会使用”。隐形只影响计划构造，不会停止索引对行变更的维护，因此它适合短周期评估，不适合长期代替清理。

用执行计划和回滚证据做删除决策

先保存几条有代表性的 SQL 及其原始计划，重点记录 possible_keys、key 和 rows。隐形后如果关键查询出现全表扫描、估算行数明显扩大，或原本不进慢查询的语句开始出现，就先恢复索引，不要急着删除。

-- 在隐形状态下观察默认计划，默认不会把目标索引列入候选
EXPLAIN SELECT order_id, total_amount
FROM orders
WHERE customer_id = 10086 AND created_at > '2026-01-01';

-- 只为这一条语句临时把隐形索引纳入计划构造，便于做对照
EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = 'use_invisible_indexes=on') */
  order_id, total_amount
FROM orders
WHERE customer_id = 10086 AND created_at > '2026-01-01';

-- 若发现回归，先恢复可见；确认无依赖后才另行安排 DROP INDEX
ALTER TABLE orders ALTER INDEX idx_orders_customer VISIBLE;
-- DROP INDEX idx_orders_customer ON orders;

use_invisible_indexes 的对照只回答“这条 SQL 是否可能从该索引获益”，不能替代真实流量观察。生产评估至少覆盖高峰查询、低频报表、定时任务和显式索引提示；将计划差异与慢查询日志、Performance Schema 中的工作负载变化一起记录。

删除前的最小检查清单

最后要区分两个动作：恢复可见是评估阶段的回滚，DROP INDEX 才是不可逆的结构变更。只有当隐形观察期覆盖了真实业务周期，并且没有计划、慢查询和提示依赖，才值得把删除放进变更窗口。

常见边界问题

隐形后还能保证唯一性吗？可以。唯一索引的约束仍然生效，隐形只改变优化器是否使用它；但如果该索引承担主键语义，可能根本不能设为隐形。

只看一次 EXPLAIN 就能删除吗？不能。EXPLAIN 是单条语句和单组参数下的计划证据，低频任务、索引提示和数据分布变化仍需要在观察窗口内验证。