这是MyISAM表损坏提示，InnoDB表不会出现；需先确认引擎类型，MyISAM可用REPAIR TABLE或myisamchk修复，InnoDB则需检查ibdata1和日志文件，不可误用MyISAM方法。
phpMyAdmin 里显示 “Table ‘xxx’ is marked as crashed and should be repaired”
这是典型的 MyISAM 表损坏提示，InnoDB 表一般不会报这句，但可能表现为查询卡死、返回空或 ERROR 2013 (HY000): Lost connection to MySQL server during query。宝塔面板默认用的是 MySQL 或 MariaDB，底层存储引擎决定修复方式——先确认引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'your_table_name';如果结果是
MyISAM，才能用 phpMyAdmin 自带的“修复表”功能；如果是 InnoDB，点修复会直接失败或无响应。
在 phpMyAdmin 中点击“修复表”没反应或报错 #1036
常见原因有两个：一是当前用户没有 REPAIR TABLE 权限（尤其宝塔新建的数据库用户默认不带该权限）；二是表名含特殊字符或大小写混用，导致 phpMyAdmin 构造 SQL 时出错。解决方法：
- 用 root 用户登录 phpMyAdmin（宝塔面板 → 数据库 → 点击“phpMyAdmin”旁的“root”链接）
- 手动执行 SQL：
REPAIR TABLE `your_db_name`.`your_table_name`;
注意必须用反引号包裹库名和表名，尤其是名字含短横线（如wp-postmeta）或大写字母时 - 若仍报
#1036 - Table is read only，说明 MySQL 配置了read_only=1（常见于主从架构），需临时关闭：SET GLOBAL read_only = OFF;
再执行修复
修复后数据丢失或部分字段变 NULL
MyISAM 的 REPAIR TABLE 是有损操作，特别是用 QUICK 模式（phpMyAdmin 默认用的就是它）。它只校验索引文件（.MYI），不检查数据文件（.MYD），所以索引坏了能救，数据块损坏就可能跳过或清空整行。真正稳妥的做法是：
- 优先尝试
REPAIR TABLE ... USE_FRM（需先停 MySQL，复制一份.frm文件备份） - 更推荐直接用
myisamchk命令行工具，支持--safe-recover模式，能逐行扫描恢复：myisamchk --safe-recover /www/server/data/your_db_name/your_table_name.MYI
路径中的/www/server/data是宝塔默认 MySQL 数据目录，务必确认实际路径（看宝塔数据库列表里的“路径”列） - 修复前务必备份整个表：
mysqldump -u root -p your_db_name your_table_name > backup.sql
InnoDB 表打不开，phpMyAdmin 显示 “#1932 - Table doesn’t exist in engine”
这不是表损坏，而是 .frm 和 .ibd 文件不匹配，或者 ibdata1 损坏。phpMyAdmin 的修复按钮对 InnoDB 完全无效。必须走命令行：
- 先确认是否启用了
innodb_force_recovery（宝塔默认关着），临时开启（修改/www/server/mysql/etc/my.cnf，在[mysqld]下加一行：innodb_force_recovery = 1），然后重启 MySQL - 能连上后立刻导出数据：
mysqldump -u root -p --single-transaction your_db_name > recover.sql
注意加--single-transaction避免锁表 - 删库重建，再导入——InnoDB 没有“在线修复”概念，强行修复大概率让整个实例崩溃
立即学习“PHP免费学习笔记（深入）”；
修复不是万能的，尤其是 MyISAM 表一旦损坏严重，REPAIR TABLE 很可能只给你留个空壳。最值得花时间做的事，其实是定期用 mysqldump 全量备份，并验证备份文件能否成功导入。
