REPAIR TABLE 是修复 WordPress 数据表损坏最安全有效的方法——不丢数据、不改结构，专治 crashed、marked as crashed 或 incorrect key file 报错；需通过 phpMyAdmin 状态栏识别损坏表，优先检查 wp_options、wp_posts、wp_postmeta；手动执行 SQL 比界面更可靠；失败时降级用 OPTIMIZE TABLE 或导出重建；InnoDB 表极少损坏，多为事务问题；修复后务必清理 wp_options 中插件残留数据。
直接修复损坏的 WordPress 数据表，REPAIR TABLE 是最有效且安全的第一步——它不丢数据、不改结构，专治 crashed、marked as crashed 或 incorrect key file 这类报错。
怎么判断哪个表真坏了？别靠猜，看 phpMyAdmin 表状态栏
登录 phpMyAdmin，选中你的 WordPress 数据库，在主表列表里注意三类信号：
- 状态列显示
crashed或in use（但实际没人在操作） - 点击某张表后顶部提示 “The table … is marked as crashed and should be repaired”
-
wp_options、wp_posts、wp_postmeta这几个大表常因插件异常退出或磁盘满而损坏，优先检查它们
如果只是查询慢或偶尔超时，大概率不是表损坏，而是索引缺失或锁等待，别急着修表。
用 SQL 手动执行 REPAIR TABLE，比点界面更稳
phpMyAdmin 界面里的“修复表”按钮有时会失败（尤其在大表或低权限托管环境），推荐直接走 SQL：
立即学习“PHP免费学习笔记（深入）”；
SEO Keyword Density
下载
SEO关键词密度优化与页面审计技能。使用场景：①提供页面路径与关键词进行SEO优化；②提升页面关键词密度；③提升搜索引擎排名；④进行SEO审计（meta标签、OG、hreflang等）。触发词：关键词密度、SEO优化、关键词优化等。
- 切换到 SQL 标签页
- 输入：
REPAIR TABLE wp_options;（把wp_options换成你怀疑的表名） - 若提示
OK或Operation successful，说明修好了 - 若报错
Can't repair table或Incorrect information in file，说明损坏较重，需先OPTIMIZE TABLE或导出重建
注意：不要对 wp_users 或 wp_usermeta 轻易 REPAIR，它们损坏通常意味着权限丢失，应优先查 wp_capabilities 字段是否被清空。
修复失败怎么办？别硬刚，换 OPTIMIZE 或重建
当 REPAIR TABLE 返回 Operation failed，说明表结构已受损，这时得降级处理：
- 先试
OPTIMIZE TABLE wp_options;——它会重建表并更新索引，对“碎片化严重但未崩溃”的表很有效 - 如果仍失败，备份该表：
SELECT * FROM wp_options INTO OUTFILE '/tmp/wp_options_backup.csv';（需 MySQL 有 FILE 权限）或用 phpMyAdmin 导出 - 删表重建：
DROP TABLE wp_options;→ 用 WordPress 安装脚本或干净备份重新导入 - 极少数情况（如 MyISAM 表头损坏），只能从最近一次完整备份恢复
托管主机（如 cPanel 共享环境）常禁用 REPAIR 和 OPTIMIZE，此时必须联系支持，或确认是否启用了 InnoDB —— InnoDB 表损坏极少，多是事务悬挂，该杀进程而不是修表。
真正麻烦的不是修表本身，而是修完之后没人检查 wp_options 里有没有残留的插件脏数据，比如 wp_rocket_settings 或 autoptimize_cache 这类字段爆满，会让下一次“修复”毫无意义。
