隐藏索引对备份无性能优化作用：它不减少写入开销、不释放磁盘空间、不降低IO压力；mysqldump不跳过索引数据，xtrabackup物理备份也完全不受影响，仅元数据标记变化，备份体积与耗时与可见索引一致。
隐藏索引对备份期间性能没有优化作用——它不减少写入开销、不释放磁盘空间、不降低IO压力，备份工具看到的仍是完整索引结构。
mysqldump 备份时隐藏索引是否跳过索引数据？
不会。mysqldump 是逻辑备份，它读取表数据并生成 INSERT 语句，不访问索引文件本身；但 SELECT * 扫描仍受索引存在影响（如覆盖索引优化被绕过），而隐藏索引对此无干预能力。更重要的是：mysqldump 默认保留 INVISIBLE 属性，但仅作为元数据写入 SQL 文件，不影响备份过程耗时或资源占用。
xtrabackup 物理备份是否受益于隐藏索引？
完全不受益。xtrabackup 直接拷贝 InnoDB 表空间文件（.ibd），所有索引 B+ 树页照常复制，无论 IS_VISIBLE = 'NO' 还是 'YES'。隐藏索引只改 optimizer 决策，不删页、不压缩、不跳过任何物理块。备份体积、时间、CPU/IO 消耗与可见索引完全一致。
为什么有人误以为隐藏索引能“减轻备份负担”？
常见混淆点有三个：
- 把“优化器忽略”等同于“存储层卸载”——其实写入路径和存储结构完全不变
- 看到
EXPLAIN不走某索引，就推断备份 SELECT 阶段也绕开了它——但 mysqldump 的全表扫描走的是聚簇索引，二级索引是否隐藏不影响扫描方式 - 混淆了备份与恢复：恢复后
INVISIBLE状态可能丢失（xtrabackup 不保存该标志），但这属于元数据一致性问题，不是性能优化手段
真正影响备份性能的关键点在哪？
如果你在备份窗口遇到压力，该调的不是索引可见性，而是：
- 控制并发度：
--parallel=4或--throttle限制 xtrabackup IO 压力 - 避开高峰期：用
pt-kill或SET SESSION max_execution_time=30000防止长查询阻塞备份 - 确认统计信息准确：
ANALYZE TABLE避免 mysqldump 内部估算偏差导致临时表膨胀 - 主键设计：宽主键会放大聚簇索引体积，直接影响备份大小——这才是该优化的层级
隐藏索引唯一能帮你做的，是在备份前快速禁用某个疑似冗余索引，观察业务查询是否退化，从而判断它是否真可删；但它本身不是性能开关，更不是备份加速器。
