先确认引擎再修复：执行SHOW TABLE STATUS LIKE 'table_name'查Engine列，若为MyISAM才可用REPAIR TABLE或myisamchk；若为InnoDB则属误报，应检查ibdata1和错误日志，禁用MyISAM修复方法。
这个错误只对 MyISAM 表有效，InnoDB 表出现它基本是误报或残留标记——先确认引擎，再动手，否则越修越乱。
怎么快速确认表是不是 MyISAM 引擎
别凭印象或错误信息判断。MySQL 里 InnoDB 表被误标为 crashed，常见于旧备份恢复后没清掉 .MYI 文件，或应用层硬塞了错误提示。
- 执行
SHOW TABLE STATUS LIKE 'your_table';，看Engine列是否为MyISAM - 更可靠的方式：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'; - 如果返回
InnoDB，立刻停手——REPAIR TABLE对它无效，还可能干扰崩溃恢复流程
在线修复：REPAIR TABLE 能用就别停服务
只要 MySQL 还能连上、表确认是 MyISAM，优先走 SQL 命令修复，业务不中断。
-
CHECK TABLE table_name;先看状态：返回Status: OK就不用修 - 基础修复：
REPAIR TABLE table_name; - 索引损坏但数据完好：
REPAIR TABLE table_name QUICK;（跳过数据校验，快） - 索引严重错乱：
REPAIR TABLE table_name EXTENDED;（重建全部索引，慢但彻底） - .MYI 文件丢失时救命：
REPAIR TABLE table_name USE_FRM;（仅靠.frm重建索引，会丢原索引）
离线修复：myisamchk 必须停服务，且注意权限和参数
当 REPAIR TABLE 报 Can't repair table, need rebuild 或直接卡住，说明底层文件已脱节，必须停 MySQL 用 myisamchk。
- 先停服务：
systemctl stop mysqld（宝塔里是mysql，不是mysqld）；再用ps aux | grep mysqld确认无残留进程 - 进数据库目录：
cd /var/lib/mysql/dbname/（路径以datadir配置为准） - 检查损坏：
myisamchk -s table_name.MYI（-s是 silent 模式，快速判断） - 保守修复（推荐起步）：
myisamchk -o table_name.MYI（跳过坏块，保数据） - 强力修复（数据已乱）：
myisamchk -r -v table_name.MYI（-v显示过程，方便定位卡点） - 修完必须改权限：
chown mysql:mysql table_name.*——否则 MySQL 启动时因权限拒绝读取，仍报 crashed
容易被忽略的三个关键点
很多人修完重启还是报错，问题往往出在这三处：
-
.frm文件损坏或跨版本（比如 MySQL 5.7 的.frm拷到 8.0 实例），会导致ERROR 1033 (HY000): Incorrect information in file；验证方式只有两个：CHECK TABLE报 Can't open file，或文件大小异常（0 字节或 >1MB） - 修复后没运行
CHECK TABLE二次确认，就以为完事——必须看到Status: OK才算真正恢复 - 误把 MyISAM 方法套在 InnoDB 表上：InnoDB 损坏通常表现为启动失败、错误日志里有
Corrupted page或innodb_force_recovery相关提示，得查ibdata1和日志文件，不是表级修复能解决的
