ALTER TABLE ... ALTER INDEX ... INVISIBLE 是元数据级瞬时操作，不提升查询性能，但可安全验证索引价值；主键不可设为不可见，FORCE INDEX 对其无效，需查 information_schema.STATISTICS 的 Visible 字段确认状态。
ALTER TABLE ... ALTER INDEX ... INVISIBLE 是 MySQL 8.0 中控制索引可见性的元数据级操作，它本身不优化查询，而是为安全测试索引效果提供前提——真正起作用的是后续的观察与决策。
直接回答你的核心疑问：这个语句不会让查询变快，但它能帮你避免“删错索引”或“加错索引”带来的性能雪崩。
怎么用 ALTER TABLE ... ALTER INDEX ... INVISIBLE 切换索引可见性
语法非常直白，但必须注意几个硬性限制和常见误操作：
-
ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE和ALTER TABLE t1 ALTER INDEX idx_name VISIBLE是唯二合法形式；不能写成SET INVISIBLE或MODIFY INDEX ... INVISIBLE，那些会报错ERROR 1064 (42000) - 主键索引（包括隐式主键）**不允许设为不可见**，执行会直接失败：
ERROR 3522 (HY000): Primary key cannot be invisible - 唯一约束（
UNIQUE KEY）可以设为不可见，但要注意：如果该列同时被其他约束或外键依赖，切换前需确认逻辑一致性 - 操作是瞬时的（只改
information_schema元数据），不锁表、不重建索引，毫秒级完成
为什么 FORCE INDEX 对隐藏索引无效
这是最容易踩坑的地方：即使你显式写了 FORCE INDEX (idx_name)，只要该索引是 INVISIBLE，MySQL 仍会忽略它，并回退到全表扫描或其它可用索引 —— 不会报错，也不会警告。
- 现象：
EXPLAIN SELECT * FROM t1 FORCE INDEX (idx_j) WHERE j = 10;显示key: NULL或用了别的索引，Extra字段里没有Using index - 原因：优化器在生成执行计划前就过滤掉了所有
Visible: NO的索引，FORCE无法绕过这层过滤 - 验证方式：
SELECT * FROM information_schema.statistics WHERE table_name = 't1' AND index_name = 'idx_j'\G查看visible字段值
如何真正测试隐藏索引的效果
光设成不可见没用，关键是怎么判断“删它是否安全”。真实压测环境里，得靠组合手段：
- 先用
ALTER TABLE t1 ALTER INDEX idx_j INVISIBLE下线索引 - 开启慢查询日志（
slow_query_log = ON）并设置合理阈值（如long_query_time = 1） - 跑实际业务 SQL 流量（不是单条
EXPLAIN），重点关注新增的慢查询是否命中原索引字段 - 对比
SHOW STATUS LIKE 'Handler_read%'中Handler_read_next/Handler_read_rnd_next是否显著上升 —— 这说明随机 I/O 增多，可能因缺失索引导致 - 必要时临时打开全局开关：
SET SESSION optimizer_switch = 'use_invisible_indexes=on';，此时隐藏索引可被优化器考虑（仅限当前 session）
容易被忽略的维护成本
隐藏索引不是“挂起”，它照常消耗资源：
- 每次
INSERT/UPDATE/DELETE都会更新该索引 B+ 树，写放大依然存在 - 占用磁盘空间（
data_length不会减少），对备份/主从同步带宽也有影响 -
ANALYZE TABLE仍会采集其统计信息（Cardinality），可能干扰优化器对其他索引的判断 - 长期闲置的隐藏索引建议定期清理：确认无影响后，用
DROP INDEX idx_j ON t1彻底移除
最常被跳过的动作是查 information_schema.STATISTICS 里的 Visible 字段 —— 很多人只记得建索引，忘了自己什么时候把它藏起来了。线上表一旦有十几个索引，混着 visible/invisible，不查字典表根本分不清哪个在干活。
