看到“table is marked as crashed”日志后，须先执行show create table确认engine=myisam，并检查错误日志中是否有“can't open file: 'tbl.myi'”等索引文件损坏佐证，排除mysql 8.0+系统表（实为innodb）的误报干扰。
这是 MyISAM 表损坏的明确信号，REPAIR TABLE 能直接修，但必须先停写、确认引擎、避开权限干扰——别一上来就进 MySQL 执行命令。
怎么确认真是 MyISAM 表损坏，不是误判？
看到 Table './db/tbl' is marked as crashed and should be repaired 日志，不代表就能直接修。得先排除干扰：
- 执行
SHOW CREATE TABLE db.tbl，看ENGINE=MyISAM是否真实存在；InnoDB 表绝不会触发这个报错 - 检查错误日志里有没有紧挨着的
Can't open file: 'tbl.MYI'或failed to read keyfile，这才是 MyISAM 索引文件损坏的佐证 - 如果表在
mysql系统库下（比如user、db），且你用的是 MySQL 8.0+，那它其实是 InnoDB 表，这个报错是误导——8.0+ 的系统表全为 InnoDB，is marked as crashed是旧日志残留或崩溃恢复阶段的误报
myisamchk 修复比 REPAIR TABLE 更可靠
REPAIR TABLE 在 MySQL 运行时调用，但 MyISAM 表损坏常伴随索引文件锁死或内存映射异常，运行中修复容易失败或静默跳过。离线用 myisamchk 更稳：
- 先停服务：
sudo systemctl stop mysqld，再ps aux | grep mysqld确保无残留进程 - 定位文件：MyISAM 表由
tbl.frm（结构）、tbl.MYD（数据）、tbl.MYI（索引）三部分组成，myisamchk主要修.MYI - 基础修复：
sudo myisamchk -r /var/lib/mysql/db/tbl.MYI；若提示Key file is old，加-o强制重建：sudo myisamchk -o -r /var/lib/mysql/db/tbl.MYI - 批量修复所有表：
sudo myisamchk --silent --force --fast /var/lib/mysql/db/*.MYI（注意路径别写错，db是数据库名）
修完启动失败？大概率是 .frm 文件校验不匹配
修复后 mysqld 启动卡住或报 Incorrect information in file: 'tbl.frm'，说明 .frm 文件头与修复后的 .MYI 不一致。这不是数据丢了，是元数据描述对不上：
- 别删
.frm！先备份：cp tbl.frm tbl.frm.bak - 用
mysql_upgrade -u root -p --force重刷系统表结构（仅限 MySQL 5.7 及以前）；8.0+ 已弃用该命令，需改用mysqld --initialize-insecure重初始化系统库（风险高，慎用） - 更安全的做法：从同版本正常实例导出
SHOW CREATE TABLE tbl，手工重建表结构（DROP TABLE+CREATE TABLE），再用INSERT INTO ... SELECT把.MYD里的数据捞回来（前提是.MYD没坏）
MyISAM 修复最易被忽略的点：修完没验证 .MYI 和 .MYD 文件大小是否回归合理范围——如果 .MYI 仍是 0 字节或远小于修复前，说明 myisamchk 实际没生效，得换 -r -v 加详细日志再试一次。
