MySQL 8.0 引入隐藏索引是为安全验证冗余索引，它对优化器不可见但仍维护数据一致性，支持瞬时切换与秒级回滚，需结合performance_schema和慢日志灰度观察。
MySQL 8.0 引入隐藏索引，根本不是为了“炫技”或凑新特性数量，而是为了解决一个真实、高频、高风险的运维痛点：你不敢删那个用了三年却没人敢动的索引。
为什么不能直接 DROP INDEX 后再观察？
因为重建索引成本不可控。对千万级以上大表，DROP INDEX + CREATE INDEX 不是秒级操作——它会锁表（或至少长时间持有元数据锁）、占用大量 I/O 和 CPU、拖慢所有写入，还可能触发主从延迟抖动。更糟的是，一旦发现查询变慢，回滚不是“undo”，而是重新建一遍，时间成本翻倍。
-
DROP INDEX后无法“后悔”，必须重走完整 DDL 流程 - 某些业务高峰期不允许任何 DDL，但又急需验证索引冗余性
- 历史遗留索引缺乏文档，没人能说清它到底支撑了哪条 SQL
INVISIBLE 索引到底“隐藏”了什么？
它只对优化器隐藏，其他一切照旧。这意味着：
- 优化器默认完全无视该索引：
EXPLAIN不显示、SELECT不走、FORCE INDEX会报错ERROR 1176 (HY000): Key 'xxx' doesn't exist - 但它仍被 INSERT/UPDATE/DELETE 实时维护：磁盘空间照占、写入性能开销照扣、UNIQUE 约束照校验（重复值仍会报错）
-
SHOW INDEX FROM t\G中Visible: NO是唯一可靠判断依据；Comment字段恒为NULL，别信它 - 主键（含隐式主键）禁止设为 INVISIBLE，否则报错
ER_PRIMARY_CANT_BE_INVISIBLE
如何安全灰度验证一个隐藏索引是否可删？
核心逻辑是：停用功能，但保留结构；用真实负载说话，而非单条 EXPLAIN。
- 先执行
ALTER TABLE t ALTER INDEX idx_name INVISIBLE;，瞬时完成（仅改元数据） - 开启双窗口监控：
– 左窗跑SELECT * FROM performance_schema.table_io_waits_summary_by_index_usage WHERE OBJECT_SCHEMA='db' AND OBJECT_NAME='t';，确认COUNT_STAR归零
– 右窗盯慢日志和performance_schema.events_statements_summary_by_digest，看是否有 Query_time 突增 - 若需定向测试某条 SQL 是否依赖该索引，用会话级开关：
SET SESSION optimizer_switch = 'use_invisible_indexes=on';，再EXPLAIN对比；切勿用GLOBAL，避免污染其他连接 - 观察周期建议 ≥ 24 小时，覆盖完整业务波峰波谷；期间若出现异常，
ALTER TABLE t ALTER INDEX idx_name VISIBLE;秒级恢复，无感
容易被忽略的三个实际陷阱
很多人以为设成 INVISIBLE 就万事大吉，结果在线上踩坑：
- 备份工具不兼容：用
mysqldump --no-create-info+ 手动建表时，INVISIBLE属性丢失，从库或还原库索引状态错乱 - ORM 或监控平台误统计：部分工具读
INFORMATION_SCHEMA.STATISTICS但忽略IS_VISIBLE字段，把隐藏索引当“活跃索引”计入冗余率报表 - 跨版本迁移失败：从 MySQL 8.0 导出含
INVISIBLE的建表语句，导入 5.7 或 8.0 以下版本直接报语法错误
真正关键的不是“怎么设 invisible”，而是“设完之后，系统里还有谁在悄悄依赖它”——这需要结合 performance_schema、慢日志、应用层埋点交叉验证，而不是只看一条命令是否成功执行。
