REPAIR TABLE仅对MyISAM表有效，InnoDB不支持，执行会报错#1064或#1286；MyISAM修复失败时应优先用myisamchk离线修复，InnoDB则需依赖crash recovery、innodb_force_recovery或备份恢复。
phpMyAdmin 里执行 REPAIR TABLE 报错 #1064 或 #1286？
不是所有存储引擎都支持 REPAIR TABLE，最常见原因是表用的是 InnoDB 引擎——它不接受这个命令，强行执行会报 #1064（语法错误）或 #1286（未知的存储引擎选项）。MyISAM 才原生支持 REPAIR TABLE，但宝塔默认安装的 MySQL/MariaDB 通常已将默认引擎设为 InnoDB。
实操前先确认引擎类型：
- 在 phpMyAdmin 中点开对应数据库 → 找到损坏表 → 查看「结构」页顶部显示的
Engine字段值 - 或者运行 SQL：
SHOW CREATE TABLE `table_name`;，看输出中ENGINE=后面是什么 - 若为
InnoDB，跳过REPAIR TABLE，直接走下一条路径
InnoDB 表提示“Incorrect key file”或“Table is marked as crashed”？
这类错误其实是 MySQL 的误报，InnoDB 本身没有“崩溃标记”机制，真正问题往往出在：事务日志不一致、数据页校验失败、或磁盘 I/O 错误导致页读取异常。此时硬执行 REPAIR TABLE 不仅无效，还可能触发强制只读锁定。
正确做法是优先尝试自动恢复：
立即学习“PHP免费学习笔记（深入）”；
- 重启 MySQL 服务（宝塔面板 → 软件商店 → MySQL → 重启），InnoDB 会在启动时自动执行 crash recovery
- 若仍报错，检查 MySQL 错误日志：
/www/wwwlogs/mysql_error.log，重点找InnoDB: Database was not shut down normally或page checksum mismatch - 确认无硬件故障后，再考虑
mysqldump导出 + DROP + 重建，而非现场修复
MyISAM 表执行 REPAIR TABLE 仍失败？注意三个开关参数
MyISAM 的 REPAIR TABLE 默认使用快速模式（QUICK），只修复索引文件，不碰数据文件。如果索引和数据都损坏，必须显式指定更彻底的模式：
-
REPAIR TABLE `table_name` QUICK;—— 仅修 .MYI，快但局限 -
REPAIR TABLE `table_name` EXTENDED;—— 逐行重建索引，适合键重复或顺序错乱 -
REPAIR TABLE `table_name` USE_FRM;—— 最激进，丢弃 .MYD 数据，仅靠 .FRM 结构重生成空表（慎用！） - 执行前务必备份整个表：
SELECT * INTO OUTFILE '/tmp/table_bak.sql' FROM `table_name`;（需 MySQL 有写入权限）
宝塔环境下 phpMyAdmin 权限不足导致 REPAIR 失败？
宝塔默认创建的数据库用户通常只授予 SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,INDEX,ALTER，而 REPAIR TABLE 需要 ALTER 权限——看起来已有，但部分 MariaDB 版本要求额外显式授权 RELOAD 或 SUPER（尤其当表涉及系统级修复逻辑时）。
临时解决方法（不推荐长期开启）：
- 用 root 用户登录 phpMyAdmin（宝塔 MySQL 设置页可查看 root 密码）
- 或在终端执行：
mysql -u root -p -e "GRANT RELOAD ON *.* TO 'your_db_user'@'localhost'; FLUSH PRIVILEGES;" - 注意：
REPAIR TABLE是 DDL 操作，执行期间表会被锁，线上业务需避开高峰
真正难处理的不是命令怎么敲，而是损坏背后是否已有数据页静默损坏——这种问题 REPAIR 命令根本不会报错，但查出来的数据可能缺行、字段截断或乱码。定期 mysqlcheck --check --all-databases 和启用 innodb_checksum_algorithm = crc32 才是防患关键。
