myisam表报“table is marked as crashed”但show tables可见，说明.frm文件存在而.myd或.myi损坏或脱节；需先确认引擎类型，再检查三文件完整性、权限及.frm兼容性，优先用repair table在线修复，失败后停服用myisamchk离线修复，最终依赖备份恢复。
MyISAM表报“Table is marked as crashed”但SHOW TABLES可见
这说明表结构（.frm）还在，但数据（.MYD）或索引（.MYI）文件已脱节或损坏。MySQL 能列出表名，却无法打开——本质是元数据与物理文件不一致。
先确认是否真为 MyISAM 引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'; 返回 MyISAM 才继续下一步。
- 检查数据库目录下三个文件是否齐全：
table_name.frm、table_name.MYD、table_name.MYI - 缺任一文件都必然报错；若仅
.MYI损坏，可用REPAIR TABLE ... USE_FRM强制重建索引 - 文件存在但属主不是
mysql用户（常见于手动拷贝或 root 直接操作），会导致权限拒绝：用chown mysql:mysql *.MYI *.MYD *.frm修正
修复前必须验证.frm文件是否被破坏或版本不兼容
.frm 是二进制格式，不是文本，不能用 vim/cat 查看内容。但它损坏或跨版本（如 MySQL 5.7 的 .frm 拷到 8.0 实例）会直接触发 ERROR 1033 (HY000): Incorrect information in file: './db/t.frm'。
验证方式只有两种：
- 尝试执行
CHECK TABLE table_name;—— 若返回Msg_text: Can't open file或Incorrect information in file，基本可判定.frm异常 - 对比文件大小：正常
.frm文件通常在几百字节到几 KB；若为 0 字节或远超常规（如 >1MB），极大概率已损坏 - 严禁用文本编辑器修改或保存
.frm文件——它含校验和，微小改动即导致 MySQL 启动失败
优先用REPAIR TABLE在线修复，别急着停服务
只要 MySQL 还能连上、表引擎确认是 MyISAM，就该首选 SQL 命令修复，无需中断业务。
- 基础修复：
REPAIR TABLE table_name; - 快速跳过索引重建（适合只丢数据不丢结构）：
REPAIR TABLE table_name QUICK; - 强制重建全部索引（耗时但更彻底）：
REPAIR TABLE table_name EXTENDED; - 索引文件丢失时救命：
REPAIR TABLE table_name USE_FRM;—— 注意：此操作会丢弃原索引，仅靠.frm重建，查询性能可能暂时下降
修复后务必再执行一次 CHECK TABLE table_name; 确认状态为 OK。如果仍报错，说明 .frm 本身不可信，需从备份恢复该文件（注意：仅 MyISAM 适用；InnoDB 的 .frm 在 5.7+ 已无实际作用）。
当REPAIR TABLE失败，myisamchk是最后手段
只有在 SQL 层完全无法响应、或修复后仍提示 Record file is crashed / Index file is crashed（对应错误码 127 / 126）时，才启用 myisamchk。
- 必须先停 MySQL：
systemctl stop mysql（否则文件被占用，myisamchk会拒绝操作） - 进入对应数据库目录：
cd /var/lib/mysql/db_name/ - 检查并修复：
myisamchk -r table_name.MYI（推荐加-r参数，自动处理大多数损坏） - 若提示 “Key block size is wrong”，说明
.MYI严重损坏，可加-o（安全模式）重试：myisamchk -ro table_name.MYI
修复完重启 MySQL，立刻用 mysqlcheck -c db_name table_name 验证。真正麻烦的不是修复动作本身，而是修复后发现数据行数对不上——那说明损坏已造成实际丢失，此时唯一可靠路径是还原备份。
