本文约 2,766 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
很多站长迁移站点图省事，直接 FTP 拉文件、phpMyAdmin 导数据库，两头一拼就上线。结果打开网站不是白屏，就是跳出一句「Table ‘xxx.wp_posts’ doesn’t exist」（表不存在），或者提示数据库连接出错。进 phpMyAdmin 一看，导入进去的表明明在，可名字前面挂的前缀不是 wp_，而是 jhk_、fcx_ 之类一长串看似乱码的字符。
这种情况十有八九是「表前缀不一致」：WordPress 靠 wp-config.php 里的一行 $table_prefix 来决定去哪些表里取数据，如果这个前缀和数据库里实际的表名对不上，程序就找不到表，自然报错。这不是数据丢了，只是一个「名字没对上号」的小问题。下面把原因和修复步骤讲透，照着做几分钟就能恢复。
故障原因分析
- 导入的表前缀与配置文件不一致。 原站当年安装时为了安全，把默认
wp_改成了自定义前缀，比如abcd_。迁移后wp-config.php里却还写着wp_，于是就找不到表。
- 导入时丢掉了原有前缀。 用工具导入 SQL 时，若勾选了「去掉/重命名表前缀」之类的选项，表名会被改写，导致和配置对不上。
- 导入到了错误的数据库。 数据库连接信息写错，程序连到了另一个空库或旧库，那里自然没有对应的表。
- 多个站点共用一个库时选错前缀。 同一数据库里存在多套 WordPress 表，配置里写的前缀属于另一个站，数据就会串。
- SQL 文件里带了建表前缀而配置没同步。 有些备份脚本会在导入时重新定义前缀，
wp-config.php没跟着改，两头不一致。
分步解决方案
第一步：先看清数据库里真实的表前缀
登录 phpMyAdmin（或宝塔数据库管理），展开对应数据库，看列表里表的公共前缀是什么。通常 wp_posts、wp_options、wp_users 这几张核心表的前缀就是答案。假设你看到的是 mysite_。
第二步：打开 wp-config.php 核对配置
通过 FTP 或面板文件管理，编辑网站根目录下的 wp-config.php，找到这一行：
// 文件路径：网站根目录/wp-config.php
// 数据库表前缀，必须与数据库中实际表名前缀完全一致
$table_prefix = 'wp_';把它改成数据库里真实的前缀，注意前缀结尾一定要带下划线，并且引号不要漏：
$table_prefix = 'mysite_';保存后刷新网站。如果恢复正常，问题解决。
第三步：同时核对数据库连接信息
如果改完前缀仍报连接错误，检查同一文件上方的连接参数是否与当前主机一致：
// 文件路径：网站根目录/wp-config.php
define('DB_NAME', 'database_name'); // 数据库名
define('DB_USER', 'database_user'); // 数据库用户名
define('DB_PASSWORD', 'database_pass'); // 数据库密码
define('DB_HOST', 'localhost'); // 数据库主机，多数为 localhost
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');这些值要向新主机服务商确认，别照抄旧服务器的。
第四步：不确定时改用「重命名表」方案
如果你希望统一成默认的 wp_，也可以在数据库里批量重命名表。用 SQL 逐张改，或借助工具。以三张核心表为例：
-- 把自定义前缀统一改回 wp_
RENAME TABLE mysite_posts TO wp_posts;
RENAME TABLE mysite_options TO wp_options;
RENAME TABLE mysite_users TO wp_users;实际站点往往有十几张表（含 postmeta、usermeta、terms、termmeta、comments 等），可以先用下面这条语句列出所有需要改的表名，逐一处理：
SELECT table_name FROM information_schema.tables
WHERE table_schema = '你的数据库名' AND table_name LIKE 'mysite_%';重命名后，把 wp-config.php 里的 $table_prefix 改回 wp_ 即可。
第五步：修正 options 表里的残留前缀
有些插件会把带前缀的表名写进 wp_options，改前缀后需同步替换，否则个别插件功能异常：
UPDATE wp_options SET option_name = REPLACE(option_name, 'mysite_', 'wp_')
WHERE option_name LIKE 'mysite_%';常见踩坑点
- 前缀末尾漏下划线。 写成
$table_prefix = 'wp';会让程序去找wpposts这种不存在的表，必须带_。 - 大小写不一致。 Linux 数据库表名区分大小写，
WP_与wp_是两回事，务必完全一致。 - 只改配置不改数据库。 两个方向任选其一就行：要么改配置去适配数据库，要么改表名去适配配置，别两边都半途而废。
- 导库时勾了「重命名前缀」。 导入前看清选项，多数情况下应保持原样导入。
- 连错数据库。 主机上可能有多个库，确认
DB_NAME指向的是含有 WordPress 表的那个。 - 改完不刷新缓存。 部分对象缓存（Redis、Memcached）会缓存旧的表结构查询，改完记得清一次缓存。
总结
手工 FTP 加导库迁移 WordPress，最容易撞上的就是「表前缀不一致」这个坎。它的原理一点也不复杂：wp-config.php 里的 $table_prefix 是程序找表的「钥匙」，钥匙对不上锁，就读不到数据。修复思路很清晰——先在 phpMyAdmin 里看清真实前缀，再把 $table_prefix 改成一致，顺便核对数据库连接信息，需要的话也可以批量 RENAME TABLE 统一前缀。只要方向选对、大小写和下划线都不出错，这个表前缀不一致的报错很快就能消除，站点就能正常打开。日常维护中还有个实用技巧：迁移前先在旧站查一次真实表前缀并记录下来，再对照数据库导入结果，就能在动手阶段提前发现不一致，避免上线后才发现打不开。另外，若担心改配置出错，也可以直接把数据库里的表重命名成配置中的前缀，让两边严丝合缝。
