优先用REPAIR TABLE table_name EXTENDED修复MyISAM索引损坏，但须先确认ENGINE=MyISAM、备份.MYD/.MYI/.FRM三文件、确保磁盘空闲≥表大小2倍；错误含“Table is marked as crashed”或“Incorrect key file”即为典型索引损坏。
直接结论：优先用 REPAIR TABLE table_name EXTENDED，但必须先停写、确认引擎、备份文件、留足磁盘空间——否则可能把能读的数据也搞丢。
怎么快速判断是不是 MyISAM 表索引损坏？
看到错误里带 Table is marked as crashed、Incorrect key file，或者 perror 126（Index file is crashed）、perror 145（Table was marked as crashed and should be repaired），基本就是 MyISAM 索引文件（.MYI）出问题了。InnoDB 不会报这种错，它靠崩溃恢复自动拉起。
验证方式很直接：
- 执行
SHOW CREATE TABLE table_name;，确认输出里有ENGINE=MyISAM - 执行
SHOW TABLE STATUS LIKE 'table_name';，看Comment列是否含crashed - 或者用
mysqlcheck -c database_name table_name，返回error : Incorrect key file就坐实了
为什么不能直接跑 REPAIR TABLE？
因为 REPAIR TABLE 默认走 QUICK 模式，只修 .MYI 索引文件，不碰 .MYD 数据文件——看起来快，但只要数据页也有隐性损坏，它就会失败，报 Failed repairing the table，然后你啥也没捞着。
更危险的是：这个操作不可逆，没备份就开干，等于把修复权交给运气。所以必须前置三件事：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 确认 MySQL 正在运行且该表无写入（或先
FLUSH TABLES WITH READ LOCK;） - 立刻备份三件套：
cp /var/lib/mysql/dbname/table_name.{MYD,MYI,FRM} /backup/ - 检查磁盘剩余空间是否 ≥ 当前表大小的 2 倍（
EXTENDED模式会生成临时文件，空间不够就中断并残留损坏碎片）
REPAIR TABLE 的三种模式怎么选？
不是所有损坏都一样，模式选错要么修不动，要么修完索引全空：
-
REPAIR TABLE table_name;：等价于QUICK，只重建索引，适合刚断电后发现Comment是crashed but recoverable这种轻度情况 -
REPAIR TABLE table_name EXTENDED;：逐行读.MYD并重建整个.MYD + .MYI，能处理绝大多数索引+数据混合损坏，但慢、吃 I/O、占空间——这才是异常宕机后的主力方案 -
REPAIR TABLE table_name USE_FRM;：仅当.MYI文件彻底丢失或myisamchk -s直接报 “Can't read indexfile” 才用；它按.FRM结构生成空索引，数据还在，但所有索引失效，后续必须跟ANALYZE TABLE或手动CREATE INDEX
修复失败后还能抢救吗？
如果 REPAIR TABLE ... EXTENDED 返回 Operation failed，说明损坏已深入数据块或文件系统层，SQL 层命令无能为力，得切到 myisamchk 底层抢救：
- 先停 MySQL：
systemctl stop mysql - 运行：
myisamchk --safe-recover --force /var/lib/mysql/dbname/table_name.MYI -
--safe-recover会尝试从.MYD中提取可读行（哪怕跳过校验失败的块），比 SQL 层的修复更“拼命” -
--force防止遇到坏块就退出，强制继续——但它可能捞出带乱码或截断的行，得人工核对
注意：myisamchk 必须在 MySQL 停止时运行，或确保表被完全锁定；它不认数据库权限，只认文件路径，操作前务必再次确认路径和文件名拼写——输错一个字母，就可能去修隔壁库的表。
