跳至內容
工具

搜尋與取代 SQL

變更網站網址,又不會破壞序列化資料

在你的瀏覽器裡執行。什麼都不會被上傳。

The change

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?
search-replace.sql

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

關於搜尋與取代 SQL

在 WordPress 資料庫上直接用 SQL 尋找取代,會破壞它所觸及的每一個序列化選項,因為儲存的字串長度不再相符。這個工具會產生安全的查詢語法,並清楚說明哪些做法並不安全。

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 reader)是靠它來辨識的。改寫它會讓每個訂閱者都把每一篇舊文章看成是全新的。WordPress 說明文件明確表示不要更改它。