mysql表损坏典型现象：myisam表报“crashed”、.frm错误或got error 134；innodb表则表现为innodb_force_recovery启动失败、查询卡死或日志提示page corruption。
MySQL 表损坏的典型现象有哪些
遇到 Table 'xxx' is marked as crashed and should be repaired、Incorrect information in file: '.frm'，或者执行 SELECT 时直接报错 Got error 134 from storage engine，基本可以判定是 MyISAM 表损坏。InnoDB 表一般不会显示“crashed”，但可能出现 innodb_force_recovery 启动失败、查询卡死、或错误日志里反复出现 Database page corruption。
用 mysqlcheck 快速检查和修复 MyISAM 表
mysqlcheck 是最直接的修复入口，它本质是调用 REPAIR TABLE，但支持批量操作，比进 MySQL 客户端一条条修更可靠。
- 先检查所有表：
mysqlcheck -u root -p --check --all-databases - 只修复指定库的损坏表：
mysqlcheck -u root -p --repair --databases your_db_name - 强制修复（跳过校验）：
mysqlcheck -u root -p --repair --force your_db_name your_table
注意：MyISAM 修复依赖 .MYI 索引文件，如果该文件彻底丢失，mysqlcheck 会提示 Can't repair table, missing .MYI file，此时只能从备份恢复。
InnoDB 表损坏不能用 REPAIR TABLE
InnoDB 不支持 REPAIR TABLE 命令，强行执行会报错 Repair operation is not supported for tables with ENGINE=InnoDB。它的损坏通常意味着事务日志（ib_logfile0）、系统表空间（ibdata1）或独立表空间（.ibd）出问题。
- 先确认是否能启动 MySQL：查
/www/server/mysql/logs/error.log，看是否有InnoDB: Database page corruption或Cannot open table - 尝试安全启动：在
/www/server/mysql/etc/my.cnf的[mysqld]段加innodb_force_recovery = 1，逐级试到 6（仅限导出数据，不可写入） - 导出后删掉旧
.ibd文件，再用ALTER TABLE xxx IMPORT TABLESPACE导入（需提前有.cfg文件）
宝塔面板里看不到 ib_logfile* 是否损坏，但重启 MySQL 失败且日志卡在 “starting InnoDB” 就高度可疑。
宝塔环境下修复前必须做的三件事
不是所有“表损坏”都真要修——很多是权限、路径或配置导致的误判。
- 确认 MySQL 进程实际运行用户：宝塔默认用
www用户跑 MySQL，但有时/www/server/mysql/data/下文件属主变成root，会导致无法读取.MYD，表现为“表损坏”，实则是权限问题 —— 执行chown -R www:www /www/server/mysql/data/ - 检查磁盘空间：
df -h /www，ibdata1增长卡住、binlog 写满都会触发异常，错误日志里常混着OS error code 28: No space left on device - 别直接在宝塔「数据库」页点「修复」：那个按钮底层调的是
REPAIR TABLE，对 InnoDB 无效，对 MyISAM 也缺乏--force和日志反馈，容易修一半中断
真正难的不是命令怎么敲，而是得先分清：是文件真坏了，还是只是宝塔没刷出最新状态、或者 MySQL 根本没读到那个表的最新结构 —— 查日志、看属主、盯磁盘，比急着修重要得多。
