REPAIR TABLE在phpMyAdmin中仅对MyISAM表有效，InnoDB表不支持该命令；需先确认引擎类型，权限不足、表名含特殊字符或read_only=1配置均会导致修复失败；默认QUICK模式有损，建议EXTENDED模式或myisamchk离线修复，并务必提前备份。
REPAIR TABLE 在 phpMyAdmin 里点一下就能触发，但**不是所有“修复表”操作都真有效**——尤其当引擎是 InnoDB、权限不足、或表名含特殊字符时，界面显示“OK”可能只是假象。
确认表确实是 MyISAM 引擎再动手
phpmyadmin 的“修复表”按钮只对 myisam 表起作用，innodb 表点它等于白点。必须先验证：
- 打开该表的「结构」页，看顶部显示的
Engine字段是不是MyISAM - 或执行 SQL：
SHOW CREATE TABLE `表名`;，检查输出中ENGINE=MyISAM - 如果结果是
ENGINE=InnoDB，立刻停手，改走重启 MySQL 或查错误日志路径
phpMyAdmin 点“修复表”没反应或报 #1036？
常见原因不是功能坏了，而是权限或语法卡住了：
- 当前数据库用户缺少
REPAIR TABLE所需的ALTER权限（宝塔默认建的用户常缺这个）→ 换root用户登录（面板数据库页点“phpMyAdmin”旁的“root”链接） - 表名含短横线（如
wp-postmeta）、大写字母或空格 → phpMyAdmin 构造 SQL 时没加反引号 → 手动进 SQL 窗口执行：REPAIR TABLE `数据库名`.`表名`; - MySQL 配置了
read_only=1（主从架构常见）→ 先执行：SET GLOBAL read_only = OFF;，再修
修复后数据变 NULL 或部分丢失？别怪 phpMyAdmin
它默认用的是 REPAIR TABLE ... QUICK 模式，只碰 .MYI 索引文件，完全不校验 .MYD 数据文件。轻度索引损坏能救，但一旦数据块出问题，就会跳过整行甚至清空字段。
- 真正想保数据，优先在 SQL 窗口手动执行：
REPAIR TABLE `表名` EXTENDED;（重建全部索引+逐行扫描） - 若仍失败，说明文件已严重损坏 → 必须停 MySQL，用
myisamchk --safe-recover /www/server/data/数据库名/表名.MYI - 所有操作前务必备份：
mysqldump -u root -p 数据库名 表名 > backup.sql
为什么有时“修复表”点了就卡住或超时？
因为 phpMyAdmin 是通过 HTTP 请求调用 MySQL 的 REPAIR TABLE，而 MyISAM 修复过程会加写锁、占大量 I/O —— 大表（比如几百 MB 以上）在 Web 界面里很容易触发超时或连接中断。
- 小表（mysqlcheck -r -u root -p 数据库名 表名
-
mysqlcheck走命令行协议，不受 PHP 超时限制，且支持--force继续修复中断任务 - 路径别写错：宝塔默认数据目录是
/www/server/data/，不是/var/lib/mysql/
