核心更新卡在“正在更新数据库”页面是因wp_options表残留core_updater.lock等升级锁记录，需用phpMyAdmin精准删除并清空对象缓存；切勿宽删lock项或硬改db_version，多站点须同步检查sitemeta表。
核心更新卡在“正在更新数据库”页面、反复跳转、后台无法访问——基本可以断定是 wp_options 表里残留了升级锁，而 WordPress 没能自动清理。
为什么 phpMyAdmin 是最直接的切入点
WordPress 升级流程依赖 wp_options 表里的锁键（如 core_updater.lock）做互斥控制。中断后这些键不会自动消失，且缓存可能掩盖真实状态。phpMyAdmin 不走 WordPress 代码栈，能绕过所有插件、主题、缓存干扰，直连数据库验证并操作。
常见错误现象包括：Error establishing a database connection（其实是锁阻塞了后续请求）、点击“立即更新”后页面刷新回原地址、后台空白或重定向循环。
- 别等锁超时：默认 15 分钟，但某些主机或插件会覆盖该逻辑，实际可能永远不释放
- 别用“修复表”功能：它对锁记录无效，
core_updater.lock是普通选项行，不是损坏表结构 - 先确认表前缀：查
wp-config.php里的$table_prefix，别硬写wp_options
精准删除升级锁记录（不是所有 lock）
执行宽泛的 DELETE FROM `wp_options` WHERE `option_name` LIKE '%lock%' 风险很高——可能误删 transient 锁、wpml 同步锁等第三方插件关键项，导致其他功能异常。
立即学习“PHP免费学习笔记（深入）”；
只删明确属于 WordPress 核心升级的锁：
core_updater.lockauto_updater.lockwp_autoupdate_core.lock- （多站点环境额外检查）
sitemeta表里的core_updater.lock
推荐分两步操作：
第一步，查出来确认：SELECT * FROM `wp_options` WHERE `option_name` IN ('core_updater.lock', 'auto_updater.lock', 'wp_autoupdate_core.lock');
第二步，只删这几条：DELETE FROM `wp_options` WHERE `option_name` IN ('core_updater.lock', 'auto_updater.lock', 'wp_autoupdate_core.lock');
db_version 不匹配时不能硬改数字
如果删完锁仍报错 “Your WordPress database is out of date”，点更新又跳回原页，说明 db_version 值滞后于当前核心版本要求——比如数据库里是 59800，而 6.4.x 要求 62000。
直接 UPDATE db_version 是危险操作：部分表结构（如 wp_site 或 wp_sitemeta）可能已变更，但数据迁移没跑完，强行改值会导致功能异常或白屏。
- 先查当前核心需要的值：打开
wp-admin/includes/upgrade.php，搜索wp_db_version - 再查数据库：
SELECT option_value FROM wp_options WHERE option_name = 'db_version'; - 值偏低 → 运行
wp core update-db --force（需 WP-CLI）；无 CLI 则临时访问/wp-admin/install.php，它会触发完整检查流程 - 值正确但还报错 → 检查是否残留
wp_upgrade_lock或wp_maybe_update_*类临时选项，一并删掉
清空对象缓存比删锁更关键
删完 core_updater.lock 后立刻刷新页面仍卡住？大概率是 Redis / Memcached 里缓存了旧的锁状态。WordPress 读缓存优先于数据库，所以你删了库里的记录，它还在从缓存里取 false。
这一步常被跳过，却是实操中最容易卡住的地方：
- 如果你用 Redis：执行
redis-cli FLUSHDB或进 Redis 管理界面清空当前 DB - 如果你用 Memcached：重启服务或使用
echo "flush_all" | nc 127.0.0.1 11211 - 如果用 WP Super Cache / LiteSpeed Cache：进插件设置页点“Delete Cache”或“Purge All”
没清缓存就等于锁还在——哪怕数据库里已经空了。
