MySQL invisible index 怎样临时让优化器使用不可见索引

在 MySQL 8.4 中，可以在 SELECT 后使用 SET_VAR(optimizer_switch='use_invisible_indexes=on') 提示，让优化器只在这一条语句期间考虑不可见索引，而不把索引改成可见。需要连续比较多条查询时，也可改当前会话的 optimizer_switch，但必须保存并恢复原值，尤其不要让连接池中的连接带着实验设置回到业务。

MySQL 官方文档：https://dev.mysql.com/doc/refman/8.4/en/invisible-indexes.html

先限定实验要改变的范围

不可见索引仍然存在，只是默认不进入优化器的候选范围。实验需要保护的不是“隐藏起来的数据”，而是查询计划的影响范围、现有连接状态，以及实验结束后的可恢复性。不可见索引不是权限隔离或数据访问控制。

最常见的误操作是：为了试一次索引，把它改为 VISIBLE；或者为一次实验修改全局配置。前者改变索引定义层面的可见性，后者扩大配置影响范围，都与“临时试一条查询”不是同一件事。

下面所有 SQL 都是面向 MySQL 8.4 的教学示例，未在本文执行。请先在获授权的隔离测试库准备独立表，不要复制建表语句到生产库后再临时决定如何处理。

只对一条查询开放不可见索引

先用一张原创实验表说明查询和索引的关系。idx_site_time 是站点、采集时间组成的普通二级索引；主键单独保留。

-- 仅在隔离测试库创建独立表，不覆盖已有业务表。
CREATE TABLE index_probe_samples (
    sample_id BIGINT NOT NULL PRIMARY KEY,
    site_id BIGINT NOT NULL,
    sampled_at DATETIME NOT NULL,
    sample_value DECIMAL(10,2) NOT NULL,
    INDEX idx_site_time (site_id, sampled_at) INVISIBLE
) ENGINE=InnoDB;

-- 确认实际版本、连接与会话开关，别把服务端当成其他分支产品。
SELECT VERSION(), CONNECTION_ID(), @@SESSION.optimizer_switch;

-- 读取该表索引定义；不可见状态在IS_VISIBLE中查看。
SHOW INDEX FROM index_probe_samples;

空表可以展示语法，却不能代表真实计划选择。要比较性能，应由读者准备与实际分布相近、已脱敏的数据；本文不提供虚构行数、扫描耗时或“优化后提升倍数”。

-- 使用当前会话配置作为基线，比较时保持查询条件一致。
EXPLAIN
SELECT sample_id, sample_value
FROM index_probe_samples
WHERE site_id = 17
  AND sampled_at >= '2026-01-01 00:00:00';

-- 提示必须紧接SELECT；只为本条语句开放不可见索引候选。
EXPLAIN
SELECT /*+ SET_VAR(optimizer_switch='use_invisible_indexes=on') */
       sample_id, sample_value
FROM index_probe_samples
WHERE site_id = 17
  AND sampled_at >= '2026-01-01 00:00:00';

-- 紧接上一条语句查看提示相关警告，避免中间插入其他查询。
SHOW WARNINGS;

若基线会话本来就是 on，两次计划不能解释成“关闭与打开”的对照；需要先明确基线配置。启用后看 EXPLAIN 的 possible_keys、key、访问类型和估算 rows：possible_keys 表示候选，key 才表示所选索引。即使开关生效，优化器仍可能认为全表扫描或其他索引代价更低。

这个开关不是按索引名精准授权，它允许本语句考虑不可见索引，而不是只允许 idx_site_time。表里存在多个不可见索引时，计划变化可能来自其中其他索引。

多条对比查询才考虑会话设置

若需要连续比较几个条件，可以使用专用连接设置 SESSION。保护点是同一个物理连接：保存、启用、查询、恢复都必须在它上面完成。通过连接池依次调用几次任意连接的 Exec，不能保证这些操作针对同一会话。

-- 以下语句必须使用同一条专用物理连接，先保存完整原值。
SET @probe_saved_optimizer_switch = @@SESSION.optimizer_switch;

-- 只修改指定flag，其他优化项保持当前设置。
SET SESSION optimizer_switch = 'use_invisible_indexes=on';

-- 连续对比时仍保留相同过滤条件，先观察估算计划。
EXPLAIN
SELECT sample_id, sample_value
FROM index_probe_samples
WHERE site_id = 17
  AND sampled_at >= '2026-01-01 00:00:00';

-- 无论查询成功或失败，客户端清理逻辑都应恢复保存的原配置。
SET SESSION optimizer_switch = @probe_saved_optimizer_switch;
SELECT @@SESSION.optimizer_switch;

这是一段顺序 SQL，不具备异常时自动收尾能力。应用程序应在 finally、defer 或等价清理路径中执行恢复；恢复失败时，不应把未知状态的连接继续归还复用，应按驱动和连接池机制处置。实验账号只保留必要读权限；若要准备索引，由另一个获授权的变更流程负责，不必给诊断请求附加DDL权限。

不要用 optimizer_switch='default' 当作恢复：它会重置所有优化项到默认值，不等于恢复进入实验前的设置。事务 ROLLBACK 也不能替代显式的会话变量恢复。本文的临时实验不需要 SET GLOBAL 或 SET PERSIST。

留下可复查的计划与配置记录

建议记录版本、连接ID、实验前的开关、索引可见性、脱敏SQL条件，以及两份EXPLAIN结果。展示计划时注明是估算信息，不把 rows 写成已扫描的真实行数。SHOW WARNINGS 的结果也应与对应语句一起保存，以免提示被忽略后误以为实验成功。

如提示写错、变量名不支持或值不合法，MySQL可能以警告说明提示被忽略；“SQL执行没有报错”不足以证明提示被采用。SET_VAR 的变量名直接写 optimizer_switch，不要在提示里写 SESSION 或 @@SESSION 前缀。

若后来要测真实耗时，应在可控环境由读者另行执行。不要把 EXPLAIN ANALYZE 当普通 EXPLAIN：它涉及实际执行查询。计划选中索引也不是一定更快的证据，仍需考虑返回行数、回表、缓存冷热和并发负载。本文没有运行这些检查，也没有展示测量结果。

这些边界不能由开关解决

不可见索引不参与查询，还要维护吗？

仍要维护。它会随着表数据变更更新，唯一索引的唯一性约束也不会因为不可见而消失。因而“隐藏后查询没变慢”不能说明写入成本已消除，更不能等价于已经删除索引。

主键也能先设成不可见再实验吗？

主键不能设为不可见。没有显式主键时，某些承担隐式主键作用的唯一非空索引也有相应限制。这里的普通二级索引实验，不应推广到所有索引类型。

打开开关后没选中，是否必须 FORCE INDEX？

不必立即强制。先确认提示与会话范围、索引列顺序、条件是否匹配，以及成本估算依据。允许候选与强制路径是两个不同决策；如果一开始就强制，容易跳过“优化器为何不选”的真正问题。

只试一条查询时，把 SET_VAR 放进该语句即可；要试一组查询，再使用专用会话并恢复原值。保持索引元数据不变、把配置影响范围收小，才符合“临时让优化器使用不可见索引”的目的。

参考：MySQL 8.4 不可见索引；optimizer_switch 设置规则；SET_VAR 提示语法。