myisamchk 修复前必须停止 mysql 服务，因其需独占表文件；-o 保守修复优先，-r 强力修复备用；修复后须修正文件属主为 mysql 并迁移至 innodb。
myisamchk 修复前必须停止 MySQL 服务
MySQL 报 Table is marked as crashed，说明 MyISAM 表的索引文件（.MYI）或数据文件（.MYD）已损坏，而 myisamchk 是专用于离线修复 MyISAM 表的命令行工具。它不能在 MySQL 正在使用该表时运行，否则会写入冲突、进一步损坏数据。
常见错误现象：直接执行 myisamchk /var/lib/mysql/dbname/table.MYI 后提示 error: Can't lock file 或修复完重启 MySQL 仍报错。
- 先停服务：
sudo systemctl stop mysql（Ubuntu/Debian）或sudo service mysqld stop（CentOS/RHEL） - 确认 mysqld 进程已退出：
ps aux | grep mysqld，无残留进程再操作 - 别用
mysqladmin shutdown替代——它可能只断开连接，不释放文件锁
myisamchk -r 和 -o 的区别直接影响修复结果
-r（recover）是“强力修复”，会重建索引、尝试恢复尽可能多的数据；-o（safe-recover）是“保守修复”，跳过无法解析的记录块，适合严重损坏但需保命的场景。选错参数可能导致数据丢失或修复失败。
使用场景：如果表还能 SELECT 出部分数据，优先试 -o；如果 SELECT 直接报错或返回乱码，再用 -r。
- 安全起步：
myisamchk -o /var/lib/mysql/dbname/table.MYI - 仍失败再升级：
myisamchk -r -v /var/lib/mysql/dbname/table.MYI（-v显示过程，便于判断卡点） - 避免用
-f（force）：它会强制覆盖，可能把还能读的索引也清掉
修复后权限和文件归属错位会导致 MySQL 启动失败
用 myisamchk 修复后，生成的新 .MYI 文件默认属于当前执行用户（如 root），而 MySQL 服务通常以 mysql 用户运行。启动时会因权限拒绝读取索引文件，报错看似仍是 “crashed”，实则是 “permission denied”。
错误现象：sudo systemctl start mysql 成功，但查表时报 Table 'dbname.table' doesn't exist 或日志里有 Can't find file: './dbname/table.frm'（其实是 .MYI 权限问题）。
- 修复后立刻修正归属：
sudo chown mysql:mysql /var/lib/mysql/dbname/table.* - 确认权限：
ls -l /var/lib/mysql/dbname/table.*应显示 owner/group 都是mysql - 别漏掉
.frm文件——虽然它一般不损坏，但归属也要一致
MyISAM 已淘汰，修复只是临时手段
MySQL 5.5+ 默认引擎已是 InnoDB，8.0 官方文档明确标注 MyISAM 为“deprecated”。myisamchk 修复成功不代表风险解除——MyISAM 无事务、无崩溃恢复、表锁粒度粗，下次突发断电或 kill -9 仍大概率再次损坏。
真正要做的事不是反复修，而是迁移：
- 检查当前表引擎：
SHOW CREATE TABLE dbname.table;看 ENGINE=MyISAM - 转成 InnoDB：
ALTER TABLE dbname.table ENGINE=InnoDB; - 注意：大表执行时会锁表，建议在低峰期操作，或用
pt-online-schema-change
修复完立刻验证数据一致性，然后排期迁移。不然下一次崩溃，你又得重走一遍停服 → myisamchk → 权限 → 启动 → 检查的流程。
