phpmyadmin“修复表”无效因默认启用quick repair，仅修索引，对崩溃的wp_posts/wp_options无效；须取消勾选quick repair再执行。优先修复wp_posts、wp_options、wp_comments三表，修复后仍500需检查wp_options中autoload字段是否为yes。
phpmyadmin里点“修复表”为什么没用？
因为默认勾选了 quick repair，它只修索引文件，对真正崩溃的 wp_posts 或 wp_options 表基本无效。你看到“ok”只是假成功，刷新页面可能立刻又报 table 'wp_posts' is marked as crashed。
正确做法是：
- 进 phpMyAdmin → 左侧选中你的 WordPress 数据库
- 点击出问题的表（比如 wp_posts）→ 顶部切到 Operations 标签页
- 找到 Repair table 区域，务必取消勾选 “Quick repair”
- 再点 Go，等执行完成 —— 成功时返回 OK，失败则显示 Operation failed
哪些表必须优先修复？
不是所有表都值得花时间修。重点盯这三张：
-
wp_posts：文章、页面、自定义文章类型全在这，损坏直接白屏或 500 -
wp_options：主题设置、插件状态、重写规则都在这，损坏会导致后台打不开、切换主题失败 -
wp_comments：评论功能瘫痪，但不影响前台访问，可延后处理
wp_users 损坏会锁死后台登录，如果已无法登录，修复它应排第二顺位；wp_usermeta 通常连带修复即可，不单独优先。
修复完还是 500 或后台空白？查 autoload 字段
这是最常被忽略的环节：修复 wp_options 表后，它的 autoload 列可能被设成 no 或空值，导致关键选项（如 rewrite_rules、active_plugins）不加载。
操作步骤：
- 在 phpMyAdmin 中打开 wp_options 表 → 点 Search
- 在 autoload 列填 no 或留空，搜一遍
- 重点关注：rewrite_rules、active_plugins、theme_mods_*、widget_*
- 执行 SQL：
UPDATE wp_options SET autoload = 'yes' WHERE option_name IN ('rewrite_rules', 'active_plugins', 'theme_mods_twentytwentythree');（把 twentytwentythree 换成你当前主题名）为什么刚修好又崩？两个底层原因必须查
反复损坏不是偶然，大概率是以下其一没解决：
-
MyISAM引擎还在用：WordPress 默认表引擎如果是MyISAM，抗崩溃能力极弱。进 phpMyAdmin 查任意表的Type列，若为MyISAM，需批量转为InnoDB（执行ALTER TABLE wp_posts ENGINE=InnoDB;） - 磁盘空间不足或
/tmp分区满：MySQL 修表时需要临时空间。SSH 登录后运行df -h和df -h /tmp，确认可用空间 >20%；若不足，清理日志或联系主机商扩容
修表只是止血，引擎和磁盘才是病根。跳过这两步，下次断电或高并发，照样再崩一次。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
