MySQL 8.0的invisible index默认被优化器彻底忽略，非bug而是设计行为；验证需对比EXPLAIN中key字段是否为空或改走其他索引，并查INFORMATION_SCHEMA.STATISTICS中IS_VISIBLE='NO'；A/B测试须显式启用use_invisible_indexes开关，禁用FORCE INDEX（会报错ERROR 1176）。

MySQL 8.0 的 invisible index 本身不参与优化器选择——这是它的核心行为，不是 bug，也不需要“启用”才能生效；真正要测的是「有/无该索引」对执行计划的影响，必须显式控制 optimizer_switch 或使用提示，否则你看到的永远是“无索引”状态。

怎么确认 invisible index 真被优化器跳过

别只看 SHOW INDEX 的 Visible: NO，它只是元数据标记。关键验证点有两个：

• EXPLAIN SELECT ... WHERE col = ? 中 key 字段为空，或改走其他索引——前提是这条 SQL 原本就依赖该索引（可通过历史慢日志或 performance_schema.table_io_waits_summary_by_index_usage 确认）
• SELECT IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't' AND INDEX_NAME = 'idx_name' 返回字符串 'NO'（注意不是布尔值，也不是 NULL）
• 若仍走该索引，立刻查 SELECT @@optimizer_switch LIKE '%use_invisible_indexes=on%'；返回 1 表示开关开着，当前会话正在“看见”不可见索引

如何做 A/B 对比：有索引 vs 无索引的真实执行计划

默认情况下，EXPLAIN 根本不会把 invisible index 纳入候选集，所以你无法直接对比。必须手动干预优化器行为：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 会话级临时启用（推荐）：SET SESSION optimizer_switch = 'use_invisible_indexes=on';，然后跑 EXPLAIN；再关掉、重跑同一语句，对比 key 和 type
• SQL 级更安全（MySQL 8.0.22+）：EXPLAIN SELECT /*+ SET_VAR(optimizer_switch = "use_invisible_indexes=on") */ * FROM t WHERE col = 1;，避免污染会话状态
• 禁止用 FORCE INDEX(idx_name) 测试——它会直接报错 ERROR 1176: Key 'idx_name' doesn't exist，因为优化器默认“看不见”它

为什么压测中发现 QPS 下降或 CPU 升高，却和查询无关

invisible index 不影响查询路径，但照常吃写入资源：

• INSERT/UPDATE/DELETE 仍实时维护 B+ 树结构和唯一性校验，开销与 visible 索引完全一致
• 实测显示：对 500 万行表加一个 invisible 索引，写入吞吐量下降约 8%，和 visible 索引几乎无差别
• 如果灰度期间观察到写入延迟上升、innodb_buffer_pool_reads 暴涨，别急着归因于查询退化——先查 information_schema.STATISTICS 确认是否误把多个索引都设为 invisible，叠加了写入负担

最容易被忽略的一点：应用代码里硬写的 FORCE INDEX 或 ORM 层自动注入的索引提示，会绕过 invisible 判断，让测试完全失真；灰度前必须全量扫描 SQL 和配置，而不是只信 EXPLAIN 输出。