必须取消“Quick repair”勾选，否则无效；操作路径为phpMyAdmin→选数据库→点问题表→Operations→Repair table→取消Quick repair→Go；优先修复wp_posts、wp_options等高频核心表。
直接修复就行，但必须取消“quick repair”勾选，否则大概率白忙活。
phpMyAdmin 里点“Repair table”却没用？取消 Quick repair 是关键
phpMyAdmin 的“Repair table”按钮默认启用 QUICK 模式，它只修索引不碰数据页——而“Table ‘xxx’ is marked as crashed”这种报错，90% 是数据页损坏，QUICK 根本无效，还会返回“OK”假象。
操作路径：进 phpMyAdmin → 左侧选中你的 WordPress 数据库 → 点击出问题的表（如 wp_posts、wp_options、wpvq_actionscheduler_claims）→ 顶部切到 Operations 标签页 → 找到 Repair table 区域 → 务必取消勾选 “Quick repair” → 点 Go。
常见错误现象：
- 点了 Repair 后页面刷新显示 OK，但网站还是白屏或报同样错误
- 修复后过几小时又出现崩溃提示——说明上次根本没修到位
哪些表优先修？别乱点全选
不是所有表都值得第一时间修。高频读写 + 结构复杂 = 最容易崩，也最影响访问。
立即学习“PHP免费学习笔记（深入）”；
按紧急程度排序：
-
wp_posts：文章、页面、自定义文章类型全在这，崩了首页/后台直接 500 -
wp_options：主题设置、插件开关、重写规则全依赖它，崩了后台打不开、切换主题失败 -
wp_comments：评论功能瘫痪，但不影响前台访问，可延后 -
wp_users：用户登录失效，若你已登出且无法登录后台，需优先处理 - Action Scheduler 表（如
wpvq_actionscheduler_claims）：后台任务卡死、定时发布失败，查 error_log 出现Unable to release actions from claim id 0就是它
别一上来就“全选 → Repair”，既慢又可能干扰正常表。
修完还是 500 或后台打不开？重点检查 wp_options.autoload
很多修复完仍异常的情况，根源不在结构损坏，而在 wp_options 表里 autoload 字段值错乱。WordPress 启动时会把 autoload='yes' 的选项全加载进内存，如果该 yes 的设成 no 或空，关键配置（比如 rewrite_rules、active_plugins）就丢了。
快速检查方式：
- 在 phpMyAdmin 中打开
wp_options表 → 点 Search → 在autoload列填no或留空搜索 - 重点关注：
rewrite_rules、active_plugins、theme_mods_XXX（XXX 是你当前主题名）、widget_XXX - 批量修正 SQL：
UPDATE wp_options SET autoload = 'yes' WHERE option_name IN ('rewrite_rules', 'active_plugins', 'theme_mods_twentytwentythree');（把twentytwentythree换成你实际主题名）
反复崩溃？盯紧磁盘空间和存储引擎
修一次好两天，过两天又崩——这不是运气差，是底层病没治。
两个硬指标必须查：
-
磁盘空间：MySQL 写入时空间不足会强制中断，导致表文件截断。SSH 运行
df -h，看/var/lib/mysql所在分区是否 ≥15% 剩余 -
存储引擎：WordPress 要求所有表用
InnoDB。MyISAM 表在异常关机后极易崩溃，且无法原子写入。在 phpMyAdmin 表概览页看Type列，非InnoDB的表要转：ALTER TABLE wp_posts ENGINE=InnoDB;
真正麻烦的不是第一次崩溃，而是修完没解决磁盘或引擎问题，结果下周同一张表又报 is marked as crashed——这时候再点 Repair，只是重复劳动。
