搜索替换 SQL

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

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

The change

Old URL New URL Table prefixCheck wp-config.php. It is not always wp_ — and on a multisite it definitely is not.

Read this before you run anything

WordPress stores many options as PHP-serialized strings, and a serialized string records its own byte length — s:19:"http://old-site.com". A plain SQL replace changes the text but not the length, so PHP can no longer unserialize the row. It does not error. The value just silently becomes empty.

What you lose: widget configuration, theme mods, and most plugin settings. Usually you do not notice until days later, and by then the backup you would have restored is gone too.

This is why the queries below deliberately do not touch wp_options.

What are you moving?

Post content and excerptspost_content and post_excerpt are plain text. Safe. Also rewrite the GUID columnDo NOT tick this unless you know why you need to. The GUID is a permanent unique identifier, not a URL — changing it makes every feed reader treat every old post as brand new. Post meta (may be serialized — risky)postmeta often contains serialized data. Ticking this shows you the query with a loud warning attached.

search-replace.sql

Take a database backup first. Not 'consider taking one' — take one. There is no undo for an UPDATE.

关于搜索替换 SQL

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

你可能还需要的其他工具

wp-config.php 生成器

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

FAQ

常见问题

我能用 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 文档明确说了不要改它。