MySQL恢复后索引“看似存在却不起作用”需分引擎处理：MyISAM用REPAIR TABLE（按CHECK结果选QUICK或EXTENDED），InnoDB须ALTER TABLE ... FORCE重建索引并ANALYZE更新统计信息。
MySQL恢复后索引“看似存在却不起作用”，不是靠OPTIMIZE TABLE就能解决的——它不校验结构完整性，对已损坏的索引页直接跳过或失败。必须按存储引擎分路径处理：MyISAM 用 REPAIR TABLE 配合模式选择；InnoDB 则不能修，得重建表并强制刷新统计信息。
MyISAM 表报 Incorrect key file for table 怎么快速修复
这是 .MYI 文件损坏的明确信号，REPAIR TABLE 是唯一有效手段，但参数选错会白忙活：
- 先运行
CHECK TABLE tbl_name：若返回status = OK，不用修；若提示record delete-link chain broken或error，再执行修复 -
REPAIR TABLE tbl_name QUICK仅重写索引树，快但不检查数据行——适合索引断裂但CHECK TABLE没报数据异常的情况 - 若
CHECK TABLE明确指出数据逻辑错误（如data record is corrupted），必须用REPAIR TABLE tbl_name EXTENDED，它逐行扫描 .MYD 并重建索引，但会锁表、IO 压力大 - 修复失败常见原因是
tmpdir空间不足：查SELECT @@tmpdir，确保空闲空间 ≥ 原索引文件大小的 2 倍，否则会卡在Can't create new tempfile
InnoDB 表恢复后 EXPLAIN 不走索引怎么办
这不是“索引损坏”，而是元数据与 B+ 树脱节，REPAIR TABLE 执行必报 Storage engine for the table doesn't support repair，且毫无意义：
- 先确认索引是否真实可用：
SHOW INDEX FROM tbl_name，重点看Cardinality是否非零；若为NULL或0，优化器已放弃该索引 - 用
ALTER TABLE tbl_name FORCE强制全量重建聚簇索引和所有二级索引——比ENGINE=InnoDB更可靠，能绕过部分缓存不一致问题 - 重建后必须立刻执行
ANALYZE TABLE tbl_name，否则优化器仍沿用旧统计信息，EXPLAIN里rows值不会变，可能继续全表扫描 - 若恢复是通过物理拷贝
.ibd文件完成的，务必确认innodb_file_per_table=ON且未执行过DISCARD TABLESPACE，否则 MySQL 无法加载索引页
修复后怎么验证索引真的生效了
命令返回 OK 只代表语法执行成功，不代表业务可用。最容易被忽略的是“修复成功但查询变慢数倍”的静默失效：
- 对含
UNIQUE索引的表，立即查重复：SELECT key_col, COUNT(*) FROM tbl_name GROUP BY key_col HAVING COUNT(*) > 1，防止修复过程跳过冲突行 - 用
EXPLAIN SELECT ...检查key列是否命中预期索引名，rows值是否明显下降（比如从 100 万降到几百） - 别只测单条语句：挑几个核心查询路径，对比修复前后慢查询日志里的
query_time和rows_examined
真正危险的是那种没报错、EXPLAIN 看似走索引、但 rows 值异常高的情况——它不会中断服务，却把性能隐患悄悄埋进生产环境。验证必须落到具体查询响应时间和执行计划细节上，不能只看命令返回值。
