必须取消“Quick repair”勾选，否则仅修索引无效；优先修复wp_posts、wp_options等核心表，并检查autoload字段是否为yes、引擎是否为InnoDB、/tmp空间是否充足及phpMyAdmin版本兼容性。
phpMyAdmin里“Repair table”点完还是报crashed？默认Quick repair根本没修数据页
你看到“table 'wp_posts' is marked as crashed”却点repair后仍报错，大概率是因为phpmyadmin默认勾选了quick repair。它只重建索引文件，对真正损坏的数据页（比如因断电、磁盘满导致的页断裂）完全无效，还会返回“ok”假象。
正确做法是：进 phpMyAdmin → 左侧选中数据库 → 点wp_posts或wp_options → 顶部切到Operations标签页 → 找到Repair table区域 → 务必取消勾选Quick repair → 点Go。
- 如果执行后显示
Operation failed，说明表损坏严重，需先检查磁盘空间：df -h和df -h /tmp，确保可用空间＞20% - 修复失败还可能因引擎是
MyISAM——查任意表的Type列，若为MyISAM，执行ALTER TABLE wp_posts ENGINE=InnoDB;转引擎 - 别全选一堆表一起修，
wp_posts、wp_options、wp_comments这三张优先处理，其余可暂缓
修复完网站还是500或后台空白？查wp_options里autoload字段是否被设成no
表修好了，但rewrite_rules、active_plugins这些关键选项没加载，往往是因为wp_options表里autoload列被设成了no或空值。这不是修复遗漏，而是MySQL修表时可能重置了该字段。
操作路径：在 phpMyAdmin 中打开wp_options表 → 点Search → 在autoload列填no或留空 → 搜一遍 → 找出rewrite_rules、active_plugins、theme_mods_*等记录 → 手动把它们的autoload值改成yes。
- 批量修复更快：执行SQL
UPDATE wp_options SET autoload = 'yes' WHERE option_name IN ('rewrite_rules', 'active_plugins', 'theme_mods_twentytwentythree');（把twentytwentythree换成你当前主题名） - 别漏掉
widget_*前缀的选项，它们控制小工具栏，缺失会导致后台布局错乱 - 改完立刻刷新后台，不要等缓存——有些主机对象缓存（如Redis）会卡住旧值，需手动
flush
刚修好几小时又崩？两个底层原因不查清，修十次也白搭
反复崩溃不是偶然，90% 是以下其一没解决：
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
-
MyISAM引擎还在用：WordPress默认建表用MyISAM，它不支持事务、崩溃恢复弱。进 phpMyAdmin 查任意表的Type列，确认是InnoDB；如果不是，批量执行ALTER TABLE wp_posts ENGINE=InnoDB;（注意：大表执行时会锁表，避开流量高峰） -
/tmp分区满：MySQL修表依赖临时空间，df -h /tmp若剩余＜10%，修表过程会被内核kill，表面成功实则中断。清理/tmp下陈旧session或MySQL临时文件，或联系主机商扩容 - 插件写入异常：某些插件（如Action Scheduler类）高频写
wp_actionscheduler_logs，若磁盘IO慢或日志未轮转，会拖垮整个表。可临时禁用对应插件观察
phpMyAdmin本身连不上或白屏？不是WordPress问题，是它自己版本太老
PHP 8.2环境下，phpMyAdmin 5.2.x及更早版本会直接报ParseError: unexpected token "string"——因为PHP 8.2把string列为保留字，而旧版代码里大量用$string作变量名。
别查wp-config.php或WordPress插件，这是phpMyAdmin自身兼容性问题：
- 执行
cat /www/server/phpmyadmin/VERSION（宝塔）或对应路径下的VERSION文件，确认版本≤5.2.1就必须升级 - 必须升到
phpMyAdmin 5.3.0+，推荐5.4.0+（适配PHP 8.3+） - 升级后仍白屏？检查
config.inc.php里$cfg['Servers'][$i]['auth_type']是否为'config'且密码错误——新版会直接抛mysqli_real_escape_string(): Argument #1 ($mysql) must be of type mysqli, null given，临时改成'cookie'验证
真正要盯住的，从来不是“修表”这个动作，而是MyISAM引擎、/tmp空间、phpMyAdmin版本这三根骨头。修表只是止血，它们才是病根。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
