90%的“建立数据库连接错误”实为wp_posts或wp_options表损坏所致，需在phpMyAdmin中取消Quick repair选项后手动修复，并重点修正autoload字段为'yes'的关键选项。
直接说结论：90% 的“建立数据库连接错误”根本不是连接问题，而是 wp_posts、wp_options 等表损坏导致 mysql 拒绝响应——用 phpmyadmin 修复时，必须取消勾选 “quick repair”，否则等于白点。
为什么 phpMyAdmin 的 “Repair” 按钮经常失效
phpMyAdmin 点击 Repair table 默认启用 QUICK 模式，它只校验索引不重建数据页。而 WordPress 表损坏（尤其断电、强制关机后）往往是 .ibd 文件头或 B+ 树结构错乱，QUICK 直接跳过这部分，返回 “OK” 但实际没修好。
常见现象：点完修复，页面仍 500 或白屏；phpMyAdmin 刷新后表名旁仍显示黄色感叹号；执行 SELECT * FROM wp_posts LIMIT 1 报错 #1194 - Table 'wp_posts' is marked as crashed。
修复前必须确认的三张表
别盲目全库修复，优先处理高频读写且崩溃后必然出问题的表：
-
wp_posts：文章、页面、自定义类型全存在这里，损坏后前台几乎必挂 -
wp_options：主题设置、插件状态、重写规则都靠它，损坏会导致后台打不开、激活插件失败 -
wp_comments：评论量大时易损坏，虽不直接致 500，但会拖慢整个查询链路
注意：wp_users 损坏会导致后台登录页直接报错，但通常不会引发“建立数据库连接错误”主提示，可暂缓。
取消 Quick repair 后的完整操作流
进 phpMyAdmin → 左侧选中你的 WordPress 数据库 → 点击 wp_posts 表 → 顶部切换到 Operations 标签页 → 找到 Repair table 区域：
立即学习“PHP免费学习笔记（深入）”；
- 务必取消勾选
Quick repair - 保持
Continue even if there are errors勾选（防止中途中断） - 点击
Go，等待执行完成（大表可能需 30 秒以上） - 成功返回
OK；若失败显示Operation failed，说明损坏严重，需先mysqldump备份再考虑重建
修复完 wp_posts 后，立即对 wp_options 执行同样流程——它常被忽略，但 autoload 字段错乱（比如 rewrite_rules 的 autoload 值是 no 或空）会让 WordPress 启动时卡死，表现和连接失败一模一样。
修复后仍报错？重点查 wp_options autoload 字段
很多用户修完表就以为结束了，结果后台还是打不开。此时大概率是 wp_options 表里关键选项的 autoload 值被写成了 no 或空字符串，WordPress 加载时跳过它们，导致主题/插件初始化失败。
- 在 phpMyAdmin 中打开
wp_options表 → 点击Search→ 在autoload列输入no或留空搜索 - 重点关注这几项：
rewrite_rules、active_plugins、theme_mods_XXX（XXX 是你当前主题名）、widget_XXX - 批量修正命令：
UPDATE wp_options SET autoload = 'yes' WHERE option_name IN ('rewrite_rules', 'active_plugins', 'theme_mods_twentytwentythree');（把twentytwentythree替换为你实际的主题文件夹名）
autoload 错乱是修复后最隐蔽的残余问题，不手动查，日志里也不会报错，只会让你反复怀疑是不是没修好。
