invisible索引是“禁用而非删除”，用于安全验证索引删除影响；需用alter table ... alter index ... invisible设置，主键不可设为不可见，检查必须查information_schema.statistics.is_visible。
INVISIBLE 索引不是“删不了”，而是“先不让你用”——它真正解决的是「删之前不敢试」这个卡点。直接删索引风险高，用 INVISIBLE 是唯一能闭环验证影响的生产级方案。
怎么把现有索引设为不可见？
ALTER TABLE 语句必须严格按语法执行，错一个词就失败：
• 必须写成 ALTER TABLE t1 ALTER INDEX idx_name INVISIBLE；写成 SET INVISIBLE 或 MODIFY INDEX 会报 ERROR 1064 (42000)
• 主键索引（含隐式主键）禁止设为不可见，执行直接失败：ERROR 3522 (HY000): Primary key cannot be invisible
• 唯一约束（UNIQUE KEY）可以设为不可见，但 INSERT/UPDATE 仍会检查该约束，失败风险不变
• 操作只改 INFORMATION_SCHEMA.STATISTICS.IS_VISIBLE 字段，长事务未提交时会被元数据锁（MDL）阻塞
为什么不能只信 SHOW INDEX？
• SHOW INDEX FROM t1 在 MySQL 8.0+ 中虽新增了 Visible 列，但很多运维脚本、旧版客户端或 ORM 工具硬编码列顺序，会漏掉它
• 真正可靠的检查方式是查系统表：SELECT INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't1' AND INDEX_NAME = 'idx_name';
• 返回 IS_VISIBLE = 'NO' 才算成功。别信 SHOW INDEX 的视觉判断
FORCE INDEX 会绕过不可见性，必须提前清理
• 应用代码、ORM 配置或 SQL 注释里写了 FORCE INDEX (idx_name)，哪怕索引已设为不可见，MySQL 仍会尝试强制使用它，并报错：ERROR 1176 (42000): Key 'idx_name' doesn't exist in table 't1'
• 这不是语法错误，而是优化器在“可见性过滤”阶段已将该索引注销，FORCE 指令找不到目标
• 必须在设为不可见前，全局扫描所有 SQL、配置文件、ORM 映射层，移除所有 FORCE INDEX、USE INDEX 提示
• 测试环境开启 general_log 或用 pt-query-digest 抓取真实执行语句，确认无残留
备份恢复后 INVISIBLE 状态可能意外失效
• mysqldump 默认保留 INVISIBLE 属性（含 /*!80000 INVISIBLE */ 注释），但物理备份工具如 xtrabackup 不保存该元数据
• 恢复后索引可能自动变回 VISIBLE，而你完全不知情
• 实操建议：
– 若用 xtrabackup，恢复后立即执行 SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, IS_VISIBLE FROM INFORMATION_SCHEMA.STATISTICS WHERE IS_VISIBLE = 'NO' 核对状态
– 把索引可见性纳入部署检查清单，和字符集、SQL_MODE 一样作为恢复后必验项
– 避免在主从切换窗口期做 INVISIBLE 操作——从库可能因 binlog format 或版本差异未同步可见性标记
EXPLAIN 查询。这些地方漏掉一个，压测结论就不可信。
