搜索替换 SQL

更改站点 URL，又不破坏序列化数据

在你的浏览器里运行。什么都不上传。

要做的更改

旧 URL 新 URL 表前缀查看 wp-config.php。它并不总是 wp_ — 在多站点上肯定不是。

在运行任何操作之前，先读一读这段

WordPress 将许多选项存储为 PHP-serialized 字符串，而序列化字符串会记录自身的字节长度——s:19:"http://old-site.com"。普通的 SQL 替换只改动文本却不改动长度，因此 PHP 便无法再反序列化该行。它不会报错，只是这个值会悄无声息地变成空值。

你会失去：小工具的配置、主题自定义设置，以及大多数插件的设置。通常你要等到几天后才会察觉，而到那时，本来能用来恢复的备份也已经没了。

这正是下面的查询有意不去触碰 wp_options 的原因。

你要迁移的是什么？

文章正文和摘要post_content 和 post_excerpt 是纯文本，安全。同时改写 GUID 列除非你清楚为什么需要，否则不要勾选。GUID 是永久性的唯一标识符，不是 URL — 改动它会让每个订阅阅读器把所有旧文章都当成全新文章。文章元数据（可能已序列化 — 有风险）postmeta 常常包含序列化数据。勾选后会显示查询语句，并附上醒目的警告。

search-replace.sql

先备份数据库。不是“考虑备份一下”——是必须备份。UPDATE 是无法撤销的。

关于搜索替换 SQL

在 WordPress 数据库上直接用 SQL 查找替换，会破坏它碰到的每一个序列化选项，因为存储的字符串长度不再匹配。本工具会生成安全的查询语句，并明确说明哪些是不安全的。

你可能还需要的其他工具

wp-config.php 生成器

生成一份正确的 wp-config.php，无需再从 2014 年的博客文章里复制粘贴

常见问题

我能用 SQL 查找替换来更改 WordPress 站点的 URL 吗？

不安全，而且这是 WordPress 圈里被传得最广的坏建议。很多选项是以 PHP 序列化字符串的形式存储的，会记录它们自己的字节长度。一个普通的 SQL 替换改了文本却不改长度，于是 PHP 悄无声息地无法反序列化那一行，值就直接消失了——连带着小工具设置、主题自定义和插件配置一起没了。

那我该用什么代替？

WP-CLI：先跑 “wp search-replace old new --all-tables --dry-run”，然后去掉 --dry-run 再跑。它懂序列化，会正确地重写长度前缀。如果你没有 CLI 权限，Better Search Replace 插件能在后台里做同样的事。

我该更新 GUID 列吗？

不该。GUID 是一篇文章的永久唯一标识符，不是链接，而 Feed 阅读器靠它来识别。重写它会让每个订阅者把每一篇旧文都当成全新的。WordPress 文档明确说了不要改它。