直接改表名不等于改成功，wp_options和wp_usermeta中硬编码的wp_字符串必须同步更新，否则会导致白屏、登录失败、角色丢失；务必先完整备份数据库，再用SELECT CONCAT生成RENAME TABLE语句批量重命名，仅UPDATE option_name和meta_key字段，切勿修改option_value，最后同步修改wp-config.php前缀并逐个测试插件兼容性。
直接改表名不等于改成功——wp_options 和 wp_usermeta 里还存着大量硬编码的 wp_ 字符串，漏掉它们，网站大概率白屏、后台登录失败、用户角色丢失。
先备份再动手，别跳过这步
phpMyAdmin 里没有“撤回”按钮。重命名表、UPDATE 字段都是不可逆操作。必须在执行任何 SQL 前，用 phpMyAdmin 的「导出」功能完整备份整个数据库（选“自定义”，勾上“添加 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT”）。别只导出表结构，要导出数据+结构。备份文件建议下载到本地，别只存在服务器上。
用 SELECT CONCAT 生成 RENAME TABLE 语句
phpMyAdmin 不支持通配符批量重命名，手动写 10+ 条 RENAME TABLE 容易漏、手抖写错。稳妥做法是让 MySQL 自己生成：
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_%';
把 your_database_name 换成你真实的数据库名，abc123_ 换成你要的新前缀（必须以字母或下划线开头，结尾带下划线）。执行后复制结果，在新 SQL 标签页里粘贴并执行。注意检查输出里是否包含插件自建表（比如 wpseo_options、wp_w3tc_cache），这些不会被 wp_% 匹配到，得手动补上。
只 UPDATE option_name 和 meta_key，别碰 option_value
option_value 里常含 PHP 序列化字符串（如 a:1:{s:10:"wp_capabilities";}），直接 REPLACE(option_value, 'wp_', 'abc123_') 会破坏字符串长度，导致 unserialize 失败，用户权限全丢。
立即学习“PHP免费学习笔记（深入）”；
- 安全更新
abc123_options.option_name：UPDATE abc123_options SET option_name = REPLACE(option_name, 'wp_', 'abc123_') WHERE option_name LIKE 'wp_%'; - 安全更新
abc123_usermeta.meta_key：UPDATE abc123_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'abc123_') WHERE meta_key LIKE 'wp_%'; - 别跑
UPDATE ... SET option_value = REPLACE(...)—— 这是最多人翻车的地方
改完别忘了 wp-config.php 和插件兼容性
数据库改完只是半程。必须同步修改根目录下的 wp-config.php 文件，把 $table_prefix = 'wp_'; 改成 $table_prefix = 'abc123_';。否则 WordPress 连表都找不到。
另外，某些插件（尤其是备份、安全、SEO 类）会在自己的表或选项值里硬写 wp_，比如存日志表名、缓存键。这类无法靠通用 SQL 修复，得进插件设置页看有没有“前缀适配”开关，或查插件文档。改完后务必停用所有插件，再逐个启用测试——很多问题就出在这一步。
