MySQL 8.0+ 通过 INVISIBLE 关键字创建或修改索引为隐藏状态，使其不被优化器选用但持续维护；主键和唯一约束索引不可隐藏；需用 EXPLAIN 验证执行计划是否跳过该索引，且 FORCE INDEX 可绕过隐藏限制。
MySQL 8.0+ 怎么创建和切换隐藏索引
隐藏索引不是删除，而是让优化器「假装看不见」——它依然存在、仍被维护（写入/更新开销照旧），但不会被 EXPLAIN 或查询执行计划选中。适合灰度验证：上线前先设为 INVISIBLE，对比性能变化。
- 创建时直接指定：
CREATE INDEX idx_name ON tbl(col) INVISIBLE; - 已有索引改隐藏：
ALTER TABLE tbl ALTER INDEX idx_name INVISIBLE; - 切回可见：
ALTER TABLE tbl ALTER INDEX idx_name VISIBLE; - 注意：主键索引（
PRIMARY KEY）和唯一约束依赖的索引不能设为隐藏，会报错ER_PRIMARY_CANT_BE_INVISIBLE
怎么确认隐藏索引是否生效
别只信 SHOW INDEX 里 Visible 列的值，关键看优化器实际行为。隐藏成功 ≠ 查询变慢，而要看执行计划有没有走这个索引。
- 用
EXPLAIN FORMAT=TRADITIONAL或EXPLAIN ANALYZE查执行计划，确认key字段不再出现该索引名 -
SHOW INDEX FROM tbl中Visible列显示NO才算设置成功 - 容易踩坑：连接 session 开了
optimizer_switch='use_index_extensions=off'等开关，可能干扰判断，建议在干净 session 测试
隐藏索引对写入性能有影响吗
有，而且和可见索引完全一样。隐藏不等于卸载——B+ 树结构照常维护，INSERT/UPDATE/DELETE 依然要更新该索引页。
- 测试方法：用
Sysbench或批量插入脚本，在VISIBLE和INVISIBLE状态下跑相同写入负载，观察innodb_rows_inserted和慢日志频率 - 真正省的是查询侧的索引扫描开销，不是存储或写入成本
- 如果一个索引写入压力大、查询几乎不用，隐藏它只是掩耳盗铃；不如直接
DROP INDEX
为什么 FORCE INDEX 能绕过隐藏索引限制
因为 FORCE INDEX 是硬指令，它让优化器跳过索引可用性检查，连隐藏索引也强制考虑。这既是便利点，也是陷阱。
- 执行
SELECT * FROM tbl FORCE INDEX(idx_name) WHERE col = ?时，即使idx_name是INVISIBLE，也会被使用 - 这意味着灰度期间如果应用代码里写了
FORCE INDEX，隐藏就失效了，得同步检查所有 SQL - 更隐蔽的问题：某些 ORM 自动生成的 SQL（如 Django 的
.extra()、MyBatis 的USE INDEXhint）也可能绕过隐藏
隐藏索引不是“开关”，而是“选择性失明”。它不改变数据结构，也不降低写入成本，唯一作用是隔离优化器决策路径。真正难的从来不是设成 INVISIBLE，而是判断哪些查询真的没用它、哪些 FORCE 漏网了、以及监控指标是否覆盖了所有访问路径。
