MySQL报“Table is marked as crashed”时，先确认存储引擎是否为MyISAM；若为InnoDB则属误判，应检查备份残留或应用逻辑错误；仅MyISAM表才适用myisamchk离线修复，且必须停服、备份、同版本工具操作，并配合REPAIR TABLE验证。
MySQL报“Table is marked as crashed”时，先确认存储引擎是否真是MyISAM
这个错误只对 MyISAM 表有意义，InnoDB 表不会触发该提示。如果表是 InnoDB 引擎，却看到这个报错，大概率是误判或日志残留——比如从旧备份恢复后未清空 .MYI 文件的崩溃标记，或应用层错误地复用了 MyISAM 风格的错误处理逻辑。
查证方式很简单：
SHOW TABLE STATUS LIKE 'your_table_name';
看 Engine 列。如果是 InnoDB，别碰 myisamchk，直接跳到 REPAIR TABLE 或重启 MySQL 后检查 innodb_force_recovery；只有确认是 MyISAM 才继续往下走。
用 myisamchk 修复前必须停掉 MySQL 服务
myisamchk 是离线工具，直接操作磁盘上的 .MYD 和 .MYI 文件。MySQL 进程只要还在运行，就可能缓存、写入或锁住这些文件，强行运行 myisamchk 极易导致二次损坏。
停服务后，还要注意路径问题：
- 默认数据目录通常是
/var/lib/mysql/your_database/，但不同安装方式（如 Homebrew、Docker、RPM）位置不同，务必用mysql -e "SHOW VARIABLES LIKE 'datadir';"确认 - 进对目录再执行，例如：
cd /var/lib/mysql/myapp_db - 运行前先备份整个表文件：
cp your_table.MYD your_table.MYD.bak && cp your_table.MYI your_table.MYI.bak
最常用的修复命令是：
myisamchk -r -v your_table.MYI
其中 -r 表示“安全修复”，会尝试重建索引并校验数据；-v 输出详细过程，方便判断卡在哪一步。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
myisamchk 报 “Client does not support authentication protocol” 或找不到命令
这不是表的问题，是环境配置问题：
-
myisamchk不在$PATH中：它通常和mysqld同包，但不随客户端安装。Debian/Ubuntu 上装mysql-client不含它，要装mysql-server或单独找mysqld包里的二进制；macOS Homebrew 用户需brew install mysql@8.0（版本号匹配你实际用的） - 权限不足：Linux 下数据文件属主常为
mysql:mysql，用普通用户跑myisamchk会失败，加sudo或切到mysql用户 - 字符集不匹配：如果表用了
utf8mb4但myisamchk版本太老（如 MySQL 5.5 自带的），可能解析失败，建议用与 MySQL 服务同版本的myisamchk
修复后启动 MySQL 仍报错，或查询返回乱码/缺失行
说明 -r 没完全救回数据。这时可尝试更激进的选项：
-
myisamchk -o -v your_table.MYI：只修复索引，不碰数据文件（适合索引损坏但数据完好） -
myisamchk -r -f -v your_table.MYI：强制修复（-f），跳过某些一致性检查，风险略高但有时能多捞几行 - 终极手段：
myisamchk --safe-recover -v your_table.MYI，它会逐行扫描.MYD并重建.MYI，速度慢但恢复率最高
修复完别急着启动 MySQL，先用 myisamchk -s your_table.MYI 做一次静默校验，输出为空才代表基本健康。然后启动 MySQL，立刻执行：
REPAIR TABLE your_table EXTENDED;
让 MySQL 再做一层验证——因为 myisamchk 修的是文件，而 MySQL 启动后会加载元信息，二者状态需对齐。
真正麻烦的不是修不修得好，而是修完才发现部分数据永久丢失了：MyISAM 没事务、没崩溃恢复机制，一旦 .MYD 文件本身有物理损坏，myisamchk 就无能为力。所以日常一定要开 myisam_recover_options=BACKUP,FORCE，并定期 mysqldump ——这比任何修复都管用。
