应先确认存储引擎类型：MyISAM表损坏表现为“crashed”标志，用myisamchk停服修复；InnoDB损坏则多为启动失败或页损坏，需检查ibdata1和日志文件，不可误用MyISAM方法。
宝塔面板里 MySQL 表报错 Table is marked as crashed and should be repaired 怎么办
直接用宝塔自带的「修复」按钮往往无效——它只是调用 REPAIR TABLE，而 MyISAM 表真正损坏时，这个命令常失败或静默跳过。必须先确认存储引擎和错误类型，再选对方法。
怎么判断是 MyISAM 还是 InnoDB 表损坏
MyISAM 表损坏会触发 crashed 标志，InnoDB 则通常表现为启动失败、innodb_force_recovery 生效或日志报 Corrupted page。执行以下命令快速定位：
mysql -uroot -p -e "SELECT table_schema,table_name,engine FROM information_schema.tables WHERE table_schema NOT IN ('information_schema','performance_schema','mysql','sys') AND (engine='MyISAM' OR engine='InnoDB');"
再查具体表状态：
mysqlcheck -uroot -p --check your_database your_table
- MyISAM 报
error : Record file is crashed或status : crashed→ 走 MyISAM 修复流程 - InnoDB 报
error : Unknown table engine 'InnoDB'或服务根本起不来 → 优先检查/www/server/data/ib_logfile*和ibdata1完整性，不是表级问题
MyISAM 表损坏：用 myisamchk 强制修复（比面板按钮可靠）
宝塔面板的「修复」本质是远程执行 REPAIR TABLE，但该语句依赖 MySQL 正常运行且不处理底层 .MYI 文件损坏。真实场景下，得停服务、进文件层操作：
- 先停止 MySQL：
systemctl stop mysqld（宝塔中叫mysql，不是mysqld，注意服务名） - 进入数据目录：
cd /www/server/data/your_database_name/ - 运行检查：
myisamchk -c -v your_table.MYI（-c检查关键索引结构） - 确认损坏后修复：
myisamchk -r -v your_table.MYI（-r强制重建索引；若仍失败，加-o尝试安全恢复） - 修完启动 MySQL：
systemctl start mysqld，再进 phpMyAdmin 验证数据是否可读
注意：myisamchk 对大表可能耗时，期间 MySQL 完全不可用；如果表含全文索引，修复后需手动重建：REPAIR TABLE your_table QUICK;
修复后数据不一致或部分丢失怎么办
MyISAM 的 myisamchk -r 在严重损坏时会丢弃无法校验的行，默认不提示。关键操作前务必备份：
- 停 MySQL 前，先打包整个库目录：
tar -czf /backup/your_db_$(date +%s).tar.gz /www/server/data/your_database_name/ - 如果修复后发现主键重复或字段值异常，说明数据页已损，只能从最近的
mysqldump备份还原（宝塔计划任务里的自动备份默认只存 7 天，检查/www/backup/database/） - 长期规避方案：把高频写入的表引擎改为 InnoDB（
ALTER TABLE your_table ENGINE=InnoDB;），它崩溃恢复能力远强于 MyISAM
真正麻烦的不是修复动作本身，而是误判引擎类型后硬套 MyISAM 流程去修 InnoDB 表——会导致 ibdata1 错位，MySQL 彻底无法启动。动手前，SHOW CREATE TABLE 看清楚 ENGINE= 后面是什么。
