mysql 8.0+ 中 repair table 仅支持 myisam，innodb 表需用 mysqlcheck --force 修复；myisam 表报“marked as crashed”才可用 repair table；损坏多因异常关机或磁盘错误，须查日志溯源。

MySQL 的 REPAIR TABLE 在宝塔里根本跑不了

因为宝塔默认用的 MySQL 是 8.0+，而 REPAIR TABLE 从 MySQL 5.7 起就对 InnoDB 表彻底失效了——它只支持 MyISAM。现在几乎没人用 MyISAM 建新表，所以直接敲 REPAIR TABLE xxx，大概率看到的是：ERROR 1031 (HY000): Table storage engine for 'xxx' doesn't have this option。

这不是权限问题，也不是宝塔限制，是存储引擎层面不支持。

• 确认引擎类型：执行 SHOW CREATE TABLE `your_table`;，看末尾是不是 ENGINE=InnoDB
• MyISAM 表极少，除非你明确建表时指定过 ENGINE=MyISAM，否则别指望 REPAIR TABLE 能起作用
• 宝塔的「数据库修复」按钮底层调用的也是这个命令，点它等于白点

InnoDB 表损坏了，真正该用 mysqlcheck + --force

InnoDB 自我恢复能力较强，多数“打不开”“报错 1030/1205/1213”的情况，并非物理损坏，而是事务状态异常或元数据不一致。这时优先走 mysqlcheck 工具，它在宝塔服务器终端里可直接用。

• 登录宝塔终端（SSH 或面板内置终端），切到 MySQL 用户权限下：sudo -u mysql mysqlcheck -u root -p --force --databases your_db_name
• --force 很关键：跳过访问拒绝、锁表失败等非致命错误，继续检查后续表
• 如果某张表真有页损坏（比如磁盘坏道导致），mysqlcheck 会报 error : Incorrect information in file: 'xxx.frm' 或 errno 14，这时才需要进一步动作
• 注意：运行前确保 MySQL 正在运行，且 your_db_name 是实际存在的库名，别拼错

遇到 Table is marked as crashed 错误，说明引擎其实是 MyISAM

这个错误信息本身就很说明问题——只有 MyISAM 才会“标记为崩溃”。如果你在宝塔日志或 PHP 报错里看到它，那这张表确实是 MyISAM，可以安全用 REPAIR TABLE，但得进 MySQL CLI 操作。

• 先连进 MySQL：mysql -u root -p，再选库：USE your_db_name;
• 执行：REPAIR TABLE your_table_name;（不是 REPAIR DATABASE，没这语法）
• 成功返回类似：your_table_name repair status OK；失败则显示 status Error，通常意味着文件已不可逆损坏
• 若反复失败，备份 .MYD 和 .MYI 文件后，考虑用 myisamchk 离线修复（需停 MySQL）：myisamchk --recover /www/server/data/your_db_name/your_table_name.MYI

最常被忽略的：损坏源头往往不在数据库本身

表“突然损坏”，90% 以上跟异常关机、强制 kill mysqld 进程、磁盘 I/O 错误、或者宝塔自动更新时 MySQL 服务未正常停止有关。单纯修表不查根因，下周可能又来一遍。

• 查系统日志：dmesg | grep -i "ext4\|ata\|nvme"，看有没有磁盘 I/O 错误或掉盘记录
• 看 MySQL 错误日志路径（宝塔里是 /www/wwwlogs/mysql.log），搜索 Aborted connection、Got an error reading communication packets，判断是否长期存在连接中断
• 禁用宝塔的「定时重启 MySQL」任务（尤其在业务高峰期），这类操作极易打断事务提交，诱发 InnoDB 状态混乱