alter table force 重建索引可修复物理备份还原后元数据与b+树脱节问题，需配合analyze table更新统计信息并手动验证cardinality、explain执行计划及唯一性约束。
ALTER TABLE 重建索引不是“修坏了的索引”，而是解决元数据与 B+ 树脱节——这问题在物理备份还原后极常见，尤其 mysqldump 没加 --single-transaction 或直接拷贝 .ibd 文件时。
为什么 SHOW INDEX 显示索引存在但 EXPLAIN 不走？
这不是索引丢了，是 InnoDB 内部统计信息（Cardinality）和实际 B+ 树结构错位了。你看到的 SHOW INDEX 结果只读 .frm 或数据字典定义，而真正决定是否走索引的是 ibd 文件里的页结构 + 统计直方图。还原后常见表现：
-
Cardinality列全为0或NULL（哪怕表有上百万行） -
EXPLAIN中key为NULL、type是ALL -
SELECT COUNT(*)正常返回，但WHERE indexed_col = ?查询慢得离谱
ALTER TABLE FORCE 比 ENGINE=InnoDB 更可靠
ALTER TABLE t ENGINE=InnoDB 是隐式重建，它依赖当前 ibd 能被正常解析；若还原时 ibd 已轻微损坏（如 LSN 断层、未提交事务残留），MySQL 会跳过部分页，导致新索引不完整。而 FORCE 强制全量重刷：
-
ALTER TABLE t FORCE等价于DROP + CREATE + INSERT SELECT，绕过所有缓存和旧页校验逻辑 - 对大表仍需锁表，但比
EXTENDED修复 MyISAM 更可控 - 执行后必须立刻跟
ANALYZE TABLE t，否则优化器继续用旧统计信息 - 别省略
FORCE—— 单写ENGINE=InnoDB在多数还原失效场景下无效
MyISAM 表不能用 ALTER TABLE 重建索引
MyISAM 的索引完全独立存在 .MYI 文件中，ALTER TABLE 只改 .frm 和重写 .MYD，不碰 .MYI。遇到 Incorrect key file for table 错误，必须用 REPAIR TABLE：
- 先
CHECK TABLE t：若报record delete-link chain broken，必须加EXTENDED -
REPAIR TABLE t EXTENDED会逐行扫描.MYD并重建.MYI，但耗时长、IO 高 - 修复前确认
SELECT @@tmpdir指向空间充足的路径（临时文件t.TMD大小 ≈ 原索引文件 ×2） - 修复后必须
FLUSH TABLES或重启 MySQL，否则缓存中的旧索引描述符仍在生效
验证修复是否真生效，别只看 OK
命令返回 Query OK 只代表语法通过，业务层面可能静默失效：
- 查
SHOW INDEX FROM t确认Cardinality非零（比如从0变成123456） - 跑
EXPLAIN SELECT * FROM t WHERE indexed_col = 'x'，检查key列是否命中预期索引名、rows是否明显下降 - 对含
UNIQUE索引的表，立即执行SELECT indexed_col, COUNT(*) FROM t GROUP BY indexed_col HAVING COUNT(*) > 1，防止修复过程跳过重复冲突 - 别跳过
ANALYZE TABLE—— 它更新的是优化器决策依据，不是可选项
真正容易被忽略的是：物理还原后，InnoDB 表的 ibd 和 frm 文件版本/校验值可能错位，这种不一致不会报错，但会让索引永远“看起来在、实则废”。FORCE + ANALYZE + 手动验证，三步缺一不可。
