必须停mysql服务再运行myisamchk，否则可能写坏文件；需先确认engine=myisam，innodb表禁用该工具；修复后须用check table和抽样查询验证。
必须先停掉 MySQL 服务，否则 myisamchk 可能写坏文件或产生误报。这是最常被跳过的一步，也是导致二次损坏的主因。
确认表确实是 MyISAM 引擎
别假设，直接查：
SHOW CREATE TABLE table_name;
输出里必须明确含 ENGINE=MyISAM。如果看到 ENGINE=InnoDB，myisamchk 完全无效——InnoDB 表靠崩溃恢复自动处理，强行用 myisamchk 会破坏文件结构。
停服务 + 切到数据目录再运行 myisamchk
MySQL 数据文件默认在 /var/lib/mysql/数据库名/，但路径可能因配置而异（比如 datadir 设置不同）。进错目录会导致 myisamchk 找不到 .MYI 文件。
- 停服务：
systemctl stop mysql（或service mysqld stop） - 确认当前目录是表所在库目录：
cd /var/lib/mysql/your_dbname - 检查文件存在：
ls -l table_name.MYI table_name.MYD table_name.FRM—— 三者缺一不可
选对修复参数：-r、-o、--safe-recover 的区别
myisamchk 不是“一键修复”，参数选错要么失败，要么丢数据：
-
myisamchk -r table_name.MYI：常规修复，适合索引损坏但数据页完好的情况；若报错127（Record-file is crashed）或144（last repair failed），说明数据文件已损，得换参数 -
myisamchk -o table_name.MYI：强制修复，跳过校验直接重建，有数据丢失风险，仅当-r失败后尝试 -
myisamchk --safe-recover --force table_name.MYI：底层级抢救，从.MYD中逐行提取可读记录，适合严重损坏；但速度慢、结果不确定，且必须配合--force避免中途退出
注意：myisamchk 默认只读检查，加任何修复参数（如 -r）才真正写入。误输成 myisamchk -r *.MYI 而没指定单个表，可能批量破坏多个表。
修复后验证与重启
修复命令返回 “OK” 不代表表能用，必须验证：
- 运行
myisamchk -c table_name.MYI再次检查状态 - 启动 MySQL：
systemctl start mysql - 登录后执行：
CHECK TABLE table_name;，确认Status是OK - 抽样查几条关键数据：
SELECT * FROM table_name LIMIT 5;—— 有些修复能重建结构但内容错乱，仅靠状态码看不出
磁盘空间不足、.FRM 文件损坏、或文件权限不对（比如 mysql 用户无写权限）都会让 myisamchk 静默失败，日志里可能只有一行 error: Can't open source file，得盯紧输出和系统日志。
