不会，除非显式强制指定；INVISIBLE索引默认对优化器不可见，不参与执行计划，但会实时更新并受唯一性约束检查。
MySQL 8.0 中 INVISIBLE 索引到底会不会被优化器用到
不会，除非你显式强制指定。MySQL 8.0 的 INVISIBLE 索引默认对优化器完全不可见——它不参与执行计划选择，不被 EXPLAIN 显示，也不会被 SELECT、UPDATE、DELETE 自动使用。这是它和普通索引最本质的区别。
但要注意：它仍会随数据变更实时更新（占用磁盘、影响写性能），也仍受唯一性约束检查（UNIQUE INVISIBLE 索引依然会报重复键错误）。
-
ALTER TABLE t ADD INDEX idx_name (col) INVISIBLE;是标准建法 - 已有索引可通过
ALTER TABLE t ALTER INDEX idx_name INVISIBLE;切换状态 - 想临时“启用”某个不可见索引？只能加
USE INDEX (idx_name)或FORCE INDEX提示，且仅对该语句生效
什么时候该用 INVISIBLE 而不是直接 DROP INDEX
核心场景是「验证索引是否真有用」但又不敢贸然删——比如线上大表、历史遗留索引、或刚上线的复合索引效果存疑。删了再加，万一发现查询变慢，回滚成本高；留着又浪费资源、拖慢写入。
INVISIBLE 就是这个中间态：停用索引功能，但保留结构，随时可秒级切回可见（ALTER TABLE t ALTER INDEX idx_name VISIBLE;），无需重建。
- 适合观察周期 > 1 天的 A/B 对比：开两个监控窗口，一边看
SHOW INDEX FROM t状态，一边查performance_schema.table_io_waits_summary_by_index_usage确认是否真没被用 - 不适合替代
DROP做长期归档——它照样占空间、照样锁表（ALTER INDEX ... VISIBLE/INVISIBLE是 instant DDL，但仍有元数据锁） - 注意权限：
INDEX权限即可操作，不需要ALTER全权限
INVISIBLE 索引在备份与复制中怎么处理
它会被 mysqldump 导出（含 INVISIBLE 关键字），也会被 mysqlpump 和物理备份（如 xtrabackup）完整保留。主从复制中，DDL 语句原样重放，从库索引状态和主库严格一致。
真正容易出问题的是人工干预场景：
- 如果用
mysqldump --no-create-info+ 手动建表，INVISIBLE属性会丢失（因为建表语句里没写） - 跨版本迁移（如从 8.0 升级到 5.7）会报错，因为低版本不认识
INVISIBLE语法 - 某些 ORM 工具或监控系统可能忽略索引可见性，把
INVISIBLE索引当成“有效索引”统计，造成误判
为什么 SHOW INDEX 里 Comment 字段显示 NULL 而不是 invisible
这是 MySQL 8.0 的设计选择：SHOW INDEX 不暴露可见性状态。真正判断依据是 Visible 列（8.0.12+ 才有），值为 YES 或 NO。老版本或部分客户端可能不显示该列，此时必须查 INFORMATION_SCHEMA.STATISTICS 表：
SELECT INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 't' AND INDEX_NAME = 'idx_name';
别依赖 Comment 或字段名后缀（比如有人习惯叫 idx_name_invisible），那只是命名习惯，和实际状态无关。
最易被忽略的一点：INVISIBLE 是索引级别属性，不是列级别——不能对联合索引里的某几列设 invisible，整个索引要么全 visible，要么全 invisible。
