WordPress数据库表损坏报错“Table ‘xxx’ is marked as crashed”时，90%可通过phpMyAdmin取消“Quick repair”后修复wp_posts等关键表，并检查wp_options autoload字段、存储引擎及磁盘空间。
WordPress报错显示“Table ‘xxx’ is marked as crashed and should be repaired”
这就是典型的 mysql 表损坏，wordpress 读不到数据直接崩给你看。别急着重装，90% 的情况用 phpmyadmin 一键修复就行——但得选对表、点对按钮、避开自动优化的坑。
- 常见错误现象：
MySQL said: #1194 - Table 'wp_posts' is marked as crashed and should be repaired或页面空白/500 错误伴随数据库连接失败日志 - 不是所有表都该修：优先检查
wp_posts、wp_options、wp_comments这三张高频读写表；wp_users损坏会导致后台无法登录 - 别在 WordPress 后台点“修复数据库”：那个功能依赖
WP_ALLOW_REPAIR常被主机禁用，且只对wp_options等少数表生效
在 phpMyAdmin 中安全执行 REPAIR TABLE 操作
phpMyAdmin 的图形化“Repair”按钮本质是执行 REPAIR TABLE SQL 命令，但它默认用的是 QUICK 模式——对严重损坏无效，还可能跳过关键校验。
- 进 phpMyAdmin → 左侧选中你的 WordPress 数据库 → 点击对应表（如
wp_posts）→ 顶部切换到Operations标签页 - 找到
Repair table区域，**取消勾选 “Quick repair”** ——这是最容易踩的坑，不取消就等于没修 - 点击
Go，等待执行完成；成功时返回OK，失败则显示Operation failed（说明损坏太深，需下一步） - 如果单表修复失败，不要反复点：先用
mysqldump备份该表结构和数据，再考虑OPTIMIZE TABLE或重建
修复后仍 500 或白屏？检查 wp_options 表的 autoload 字段
wp_options 表损坏常表现为后台打不开、主题切换失败、插件激活报错，而修复后仍异常，大概率是 autoload 字段值错乱（比如该为 yes 的设成了 no 或空字符串）。
- 在 phpMyAdmin 中打开
wp_options表 → 点击Search→ 在autoload列填入no或空值搜索 - 重点检查这几项：
theme_mods_XXX、widget_XXX、rewrite_rules，它们的autoload必须是yes - 批量修正：执行 SQL
UPDATE wp_options SET autoload = 'yes' WHERE option_name IN ('rewrite_rules', 'active_plugins', 'theme_mods_twentytwentythree');（按你实际主题/插件名调整）
为什么有些表修完立刻又崩溃？盯紧存储引擎和磁盘空间
反复损坏不是运气差，而是底层条件没解决。MyISAM 表比 InnoDB 更容易标记为 crashed，而磁盘满、突然断电、低配 VPS 的内存不足都会触发它。
Chinese Sensitive Words
下载
中文敏感词/违禁词检测与内容合规性检查工具。支持对小红书（Xiaohongshu）、Douyin（抖音）、WeChat（微信）、Weibo（微博）、Bilibili（哔哩哔哩）、Zhihu（知乎）、Taobao（淘宝）、JD.com（京东）等主流平台的禁用词、限用词及高风险词进行文本扫描与合规性分析。
- 查引擎类型：在 phpMyAdmin 点开任意表 →
Structure标签页看Type列，如果是MyISAM，建议转成InnoDB（执行ALTER TABLE wp_posts ENGINE=InnoDB;） - 查磁盘空间：SSH 运行
df -h，根分区或/var/lib/mysql所在分区使用率超 90% 就必须清理，否则修完几小时又崩 - 主机商限制：部分共享主机禁用
REPAIR TABLE，此时看到#1044 - Access denied错误，只能联系客服或换环境
真正麻烦的不是修表动作本身，而是修完不验证、不查引擎、不看磁盘——结果第二天同一张表又报错，还以为是 phpMyAdmin 不灵。
立即学习“PHP免费学习笔记（深入）”；
