Java应用中利用MySQL 8.0隐藏索引评估效果，核心是不改业务逻辑、不中断事务、不依赖重启——通过数据库端瞬时切换与JDBC会话级精准控制实现。
Java 应用中利用 MySQL 8.0 隐藏索引评估新索引效果，核心是「不改业务逻辑、不中断事务、不依赖应用重启」——靠数据库端瞬时切换 + JDBC 精准控制会话行为实现。
创建隐藏索引并确保对业务透明
新索引必须从创建起就设为 INVISIBLE，避免任何业务请求意外走它：
- 用 DDL 直接建隐藏索引：
CREATE INDEX idx_order_status ON orders(status) INVISIBLE; - 不要在应用启动时或 migration 脚本里执行
VISIBLE操作，否则可能被正在运行的查询捕获 - 确认生效查
INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE = 'NO'，而非只看SHOW INDEX的 Visible 字段（后者更可靠）
在 JDBC 会话中安全启用隐藏索引做对比测试
不能全局开启 use_invisible_indexes=on，必须限定在专用测试连接内：
- 单独配置一个测试数据源（如 HikariCP 的
testDataSource），连接参数加sessionVariables=optimizer_switch='use_invisible_indexes=on' - 或在测试代码中显式执行：
connection.createStatement().execute("SET SESSION optimizer_switch = 'use_invisible_indexes=on'"); - 关键：所有对比 SQL（启用/禁用状态下的
EXPLAIN和实际执行）必须复用同一 Connection 实例，避免会话隔离干扰
真实负载下观测，而非仅看单条 EXPLAIN
JDBC 层无法直接读 performance_schema，需结合可观测性手段：
立即学习“Java免费学习笔记（深入）”；
- 开启 MySQL 慢日志，并设置
long_query_time = 0.1，重点抓取命中该索引字段（如WHERE status = ?）的语句耗时变化 - 在 Java 侧用 AOP 或 DataSource 代理，在执行关键查询前后打点记录
System.nanoTime()，比对启用/禁用索引时段的 P95 延迟 - 检查
performance_schema.events_statements_summary_by_digest中对应 SQL digest 的avg_timer_wait是否下降 ≥30%，且rows_examined显著减少
事务安全与快速回滚机制
隐藏索引本身不影响事务原子性，但操作需规避锁和主键限制：
-
ALTER TABLE ... ALTER INDEX ... INVISIBLE/VISIBLE是元数据变更，毫秒完成，不阻塞事务中的 DML - 禁止对主键或隐式主键（首个 UNIQUE NOT NULL）执行该操作，否则报错
ER_PRIMARY_CANT_BE_INVISIBLE - 灰度期间若发现事务延迟上升或死锁增多，立即执行
ALTER INDEX ... VISIBLE，无需重启应用或重连连接池
