必须先批量重命名表再更新关键字段值：用SELECT CONCAT生成RENAME TABLE语句改表名，再UPDATE abc123_options.option_name和abc123_usermeta.meta_key中wp_为新前缀，option_value因含序列化数据不可直接REPLACE。
怎么在 phpMyAdmin 里批量改 WordPress 表前缀
直接改表名不等于改成功——wordpress 还会从 wp_options、wp_usermeta 等表里读取旧前缀的选项和数据，漏掉这些，网站大概率白屏或登录失败。
别手动一条条 UPDATE，容易漏字段、写错 WHERE 条件。核心是两步：改表名 + 改关键表里的字符串值。
- 先用 SQL 批量重命名所有
wp_开头的表（比如改成abc123_） - 再更新
abc123_options表里的option_name和option_value字段，把残留的wp_替换成新前缀 - 同样处理
abc123_usermeta表的meta_key字段（比如wp_capabilities→abc123_capabilities）
phpMyAdmin 执行批量表重命名的 SQL 怎么写
phpMyAdmin 不支持通配符重命名，得生成一串 RENAME TABLE 语句。最稳的方式是先查出所有旧表，拼成 SQL 再执行：
SELECT CONCAT('RENAME TABLE `', table_name, '` TO `', REPLACE(table_name, 'wp_', 'abc123_'), '`;')
FROM information_schema.tables
WHERE table_schema = 'your_database_name' AND table_name LIKE 'wp_%';
把结果复制出来，粘贴进 SQL 栏执行。注意替换 your_database_name 为真实库名，abc123_ 换成你要的新前缀（必须以字母或下划线开头，不能纯数字）。
- 执行前务必备份整个数据库——重命名不可逆
- 如果表名里有连字符（如
wp_my-plugin_data），REPLACE仍能正确替换，但确保新前缀不含非法字符 - 别忘了检查是否有自定义表没被
wp_%匹配到（比如wpseo%或woocommerce%），它们也得手动加进重命名列表
哪些表里的字段内容必须 UPDATE，不改就挂
只改表名，wp_options 里存的 siteurl、home 还是好的，但以下字段值里的前缀字符串不换，插件、主题、用户角色全乱套：
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
立即学习“PHP免费学习笔记（深入）”；
-
abc123_options表：option_name字段含wp_的行（如wp_user_roles），以及option_value里序列化字符串中的wp_（例如a:1:{s:10:"wp_capabilities";...}） -
abc123_usermeta表：meta_key字段含wp_的行（如wp_user_level、wp_dashboard_quick_press_last_post_id） - 某些插件会在自己的表里硬编码前缀（比如备份插件存日志表名），这类得看插件文档，不能靠通用脚本
安全做法是用下面这句更新 option_name（对 option_value 要小心，序列化字符串不能直接 REPLACE，否则长度错乱）：
UPDATE `abc123_options` SET `option_name` = REPLACE(`option_name`, 'wp_', 'abc123_') WHERE `option_name` LIKE 'wp_%';
为什么不能用 PHP 脚本一键替换所有 option_value
因为 option_value 里大量存的是 PHP 序列化字符串，比如 a:2:{s:13:"wp_user_level";s:1:"10";s:16:"wp_capabilities";a:1:{s:13:"administrator";b:1;}}。直接 REPLACE 会破坏字符串长度标记（s:13 变成 s:17 却没改数值），反序列化失败，后台直接 500。
- 真要批量修
option_value，得用 PHP 函数unserialize()→ 修改键名 →serialize()，没法靠 SQL 完成 - 多数情况下，只要
option_name和meta_key改对，WordPress 自身逻辑就能绕过旧前缀读写；插件是否兼容，取决于它自己有没有写死前缀 - 最省事的底线：至少确保
wp_user_roles、wp_user_level、wp_capabilities这几个关键meta_key和option_name已更新，其他可等报错再修
改完立刻清空对象缓存（如果用了 Redis/Memcached），并删掉 wp-content/object-cache.php（如果有）。否则旧缓存可能让问题延迟暴露。
