WordPress升级中断导致白屏是因MySQL元数据锁（MDL）卡死，需在phpMyAdmin中执行SHOW PROCESSLIST;定位并KILL对应ID进程，再删除wp_options表中的core_updater.lock等残留项。
WordPress升级中断后网站白屏，phpMyAdmin里看到 wp_options 表状态为 Waiting for table metadata lock
这是典型的 mysql 元数据锁（mdl）卡死，不是数据损坏，但会阻塞所有读写。升级过程中如果 php 脚本意外终止（超时、内存溢出、手动刷新），mysql 可能没来得及释放对 wp_options 或 wp_usermeta 等高频表的写锁，后续请求全被挂起。
实操建议：
- 先确认锁源：在 phpMyAdmin 的
SQL标签页执行SHOW PROCESSLIST;，找State列含Waiting for table metadata lock的行，记下对应ID - 重点看
Command是Sleep还是Query；如果是Query且Info显示UPDATE wp_options SET option_value = ...，基本就是它 - 不要直接删
wp_options表——它存着站点 URL、主题设置等核心配置，删了网站直接不可用
在 phpMyAdmin 中安全终止锁定进程，不重启 MySQL
MDL 锁不能靠“解锁命令”释放，必须干掉持有锁的连接。关键点：只杀特定 ID，别误杀其他正常连接（比如你自己的 phpMyAdmin 会话）。
实操建议：
- 回到
SHOW PROCESSLIST;结果页，找到问题行的ID（比如是12345） - 执行
KILL 12345;—— 注意没有分号以外的符号，也不加引号 - 再执行一次
SHOW PROCESSLIST;确认该 ID 消失，且不再有Waiting for table metadata lock状态 - 如果杀完仍卡住，说明可能有多个锁链（比如一个锁触发另一个等待），重复查 + 杀，通常最多 2–3 个
杀完进程后 WordPress 仍报错“另一进程正在更新”，或后台进不去
这是 WordPress 自己写的防并发升级锁机制在作祟：wp_options 表里有个 core_updater.lock 选项没清理干净，或者 wp_options.option_name 字段残留了临时值。
实操建议：
- 在 phpMyAdmin 中打开
wp_options表，搜索option_name=core_updater.lock，直接点击右侧的删除图标删掉整行 - 顺便检查有没有
option_name以doing_cron或update_core开头的异常项，一并删掉（正常运行时这些是瞬态键，不应长期存在） - 如果后台仍提示“另一进程正在更新”，清空浏览器缓存并硬刷新（
Ctrl+Shift+R），避免 JS 缓存了旧的 AJAX 错误响应
如何避免下次升级又锁死？关键不是“更快”，而是“更稳”
锁死主因是 PHP 执行时间短 + 升级包大 + 主机资源紧，不是 WordPress 本身有问题。自动升级在共享主机上尤其危险。
实操建议：
- 升级前手动备份：用插件导出
wp_options和wp_users表，或用 phpMyAdmin 导出整个库（Export→Custom→ 勾选wp_options,wp_users,wp_usermeta） - 改用 WP-CLI 升级：
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && php wp-cli.phar core update --force，它比网页端更可控、不依赖浏览器超时 - 如果只能网页升级，先在
wp-config.php顶部加set_time_limit(300);（5 分钟），并确保memory_limit不低于256M
锁表本身不可怕，可怕的是凭感觉删表、重启服务、或反复刷新升级页——这会让锁堆叠得更难解。真正耗时间的从来不是操作步骤，而是定位那个藏在 PROCESSLIST 里不肯露头的 ID。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
