MENU
  1. ホーム
  2. 技術備忘録
  3. 【実録】WP-Sweepで消えなかったTransientをphpMyAdminで確認した記録

【実録】WP-Sweepで消えなかったTransientをphpMyAdminで確認した記録

技術備忘録
  • URLをコピーしました！

WP-Optimizeを削除したあと、データベース内に関連するTransientが残っていることに気づきました。

WP-Optimizeは、以前データベースの掃除目的で使っていたプラグインです。
その後、キャッシュ機能などは自分の運用には合わないと感じ、削除してWP-Sweepへ切り替えました。

ところが、WP-Sweepで不要データを確認していると、削除したはずのWP-Optimize由来と思われるデータが、まだデータベース内に残っていました。

この記事は、WP-Sweepで見えている不要データの数と、phpMyAdminで確認した実際のデータベース上の数を照合し、残っていたWP-Optimize由来のTransientを確認・削除した実録Logです。
データベースを直接操作する内容を含むため、実行する場合は必ず事前にバックアップを取ってください。

目次

WP-Sweepで確認した不要データの数

まずは、WP-Sweepで不要データの数を確認します。

WP-Sweepでは、リビジョン、削除済みコメント、Transientなど、WordPress内に残っている不要データの件数を確認できます。
今回は、WP-Sweepが表示している数と、実際にデータベース上に存在する数が一致しているのかを確認してみることにしました。

リビジョンの初期レコード数

この時点で、リビジョンの数は50件でした。

Transient初期レコード数

Transientは33件と表示されています。

ここから、phpMyAdminを使って実際のデータベース内を確認していきます。

phpMyAdminで実際の件数を確認する

phpMyAdminにログインし、対象のデータベースを選択します。
そのうえでSQLタブを開き、まずはリビジョンの件数を確認します。

ここから先はデータベースを直接確認する作業です。確認用のSELECT文だけなら比較的安全ですが、DELETE文を実行する場合は必ずバックアップを取ってください。また、テーブル接頭辞が wp_ 以外の場合は、自分の環境に合わせて読み替える必要があります。

SELECT * FROM wp_posts WHERE post_type = 'revision';

このクエリで、wp_posts テーブル内にあるリビジョンを確認できます。

結果は50件でした。
WP-Sweepで表示されていたリビジョン数と一致しています。

次に、Transientを確認します。

SELECT * FROM wp_options WHERE option_name LIKE '_transient_%';

こちらも33件でした。
WP-Sweepが表示していたTransientの数と、データベース上の件数は一致しています。

つまり、WP-Sweepの表示はおかしくありません。
実際にデータベース内に、33件のTransientが存在している状態でした。

削除したはずのWP-Optimize由来のTransientが残っていた

Transient-（一時データ）

Transientの中身を見ていくと、削除済みのWP-Optimizeに関係していそうなデータが残っていました。

Transientとは、WordPressやプラグインが一時的なデータを保存する仕組みです。
一定時間だけ使うキャッシュのようなものですが、プラグインを削除したあとも、関連するTransientが残ることがあります。

今回は、WP-Optimizeを削除したあとにも、wpo を含むTransientが残っていました。

まずはWP-Sweepで削除できるか試す

phpMyAdminから直接削除することもできますが、いきなりデータベースを触るのは危険です。
まずはWP-Sweepを使い、安全な範囲で削除できるか試しました。

リビジョンの削除は正常に完了しました。
しかし、WP-Optimize由来と思われるTransientは、WP-Sweepを実行しても件数が変わりません。

最初に確認したTransientの件数は33件。
WP-Sweepを実行したあとも、表示は33件のままでした。

本当に消えていないのかを確認するため、再びphpMyAdminでTransientの件数を確認します。
結果はやはり33件。つまり、WP-Sweepの表示どおり、対象のTransientは残ったままでした。

なぜWP-Sweepで削除できなかったのかを考える

ここで、なぜWP-Sweepでは削除できなかったのかを考えてみました。

  1. WP-Sweepの削除対象に入らなかった可能性
    WP-SweepがどのTransientを削除対象にするかは、プラグイン側の処理に依存します。期限切れのように見えても、条件によっては対象外になる可能性があります。
  2. Transientの形式や名前が特殊だった可能性
    プラグイン由来のTransientは、名前や保存形式が一定ではありません。今回の wpo 関連データが、WP-Sweepの掃除対象として扱われなかった可能性があります。
  3. キャッシュや環境の影響を受けていた可能性
    オブジェクトキャッシュやサーバー側のキャッシュが関係して、管理画面上の表示や削除処理に影響していた可能性もあります。ただし、これはあくまで推測です。

この時点では、はっきりした原因までは断定できません。
ただ、WP-Sweepで削除を実行しても、データベース上には対象のTransientが残っていることは確認できました。

Transientの有効期限を確認する

次に気になったのが、Transientに設定されている有効期限です。

WordPressのTransientには、有効期限を持つものがあります。
その期限は、人間が読みやすい日付ではなく、Unix時間と呼ばれる数字で保存されていることがあります。

Unix時間は、1970年1月1日からの経過秒数で時間を表す形式です。
人間にはただの大きな数字に見えますが、変換すると実際の日付を確認できます。

今回確認した対象Transientの有効期限は、1774971412 という数字でした。

変換してみると、対象のTransientはすでに期限切れになっていました。
記事作成時点から見ても、数日前に期限が切れている状態です。

つまり、少なくとも今回確認したデータは、削除済みプラグインに関係しているように見え、さらに有効期限も切れていました。
それでもWP-Sweepでは削除されず、データベース内に残っていたことになります。

1件だけ手動削除して件数の変化を確認する

Transient-（一時データ）

いきなりまとめて削除するのは危険です。
そこで、まずはphpMyAdmin上で対象のTransientを1件だけ手動削除し、WP-Sweep側の件数がどう変わるか確認しました。

この時点でも、事前にバックアップを取っています。
データベースを直接触る作業では、バックアップなしで進めない方が安全です。

1件削除したあとにWP-Sweepを確認すると、Transientの件数は33件から32件に減っていました。

これで、phpMyAdmin上で確認している対象データと、WP-Sweepが表示しているTransient件数がつながっていることも確認できました。

WP-Optimize由来のTransientをSQLで削除する

1件だけ手動で削除し、WP-Sweep側の件数も減ることを確認できました。
これで、phpMyAdmin上で見ているWP-Optimize由来と思われるTransientと、WP-Sweepが表示している件数がつながっていることも分かりました。

ここから、残っているWP-Optimize由来のTransientをSQLで削除します。

ここから先はデータベースを直接削除する操作です。実行前には必ずバックアップを取り、削除対象を確認してから進めてください。テーブル接頭辞が wp_ ではない環境では、そのまま使えません。

当時は、WP-Optimize由来と思われるTransientを削除するために、次のSQLを実行しました。

DELETE FROM wp_options WHERE option_name LIKE '_transient_wpo_%';

このSQLで、option_name に _transient_wpo_ を含むTransientを対象にしました。

実行後、WP-Optimize由来と思われるTransientが5件削除されました。

その後、WP-Sweep側でも件数を確認します。

最初に確認したTransientは33件。
1件を手動で削除し、その後5件をSQLで削除したため、残りは27件になりました。

phpMyAdminで確認した件数とWP-Sweep側の表示も一致しています。
これで、今回見つけたWP-Optimize由来のTransientは削除できたことを確認できました。

補足｜LIKEでアンダースコアを正確に扱う書き方

今回のように option_name を条件にしてデータを探すときは、SQLの LIKE を使うことがあります。

LIKE は、完全一致ではなく「この形に合うもの」を探すための書き方です。
たとえば、_transient_wpo_ で始まるデータを探したい場合に使います。

ただし、SQLの LIKE では、アンダースコア _ は少し特殊です。
普通のアンダースコアではなく、「何か1文字」として扱われます。

そのため、_transient_wpo_ という文字列をできるだけ正確に指定したい場合は、ESCAPE を使い、_ を普通の文字として扱うための書き方をします。

ここで出てくる ESCAPE '!' は、! を「エスケープ記号」として使う、という指定です。

エスケープ記号とは、直後にある特殊な意味を持つ文字を、普通の文字として扱わせるための目印のようなものです。

今回の場合、LIKE の中では _ が「何か1文字」という意味を持ってしまいます。
そこで !_ と書くことで、「この _ は特殊な記号ではなく、普通のアンダースコアとして読んでください」と指定しています。

SELECT *
FROM wp_options
WHERE option_name LIKE '!_transient!_wpo!_%' ESCAPE '!';

このSELECT文で、_transient_wpo_ で始まるレコードだけが表示されるか確認します。

SELECT文で削除対象が想定どおりであることを確認できたら、同じ条件でDELETE文を実行します。

DELETE
FROM wp_options
WHERE option_name LIKE '!_transient!_wpo!_%' ESCAPE '!';

大切なのは、SELECT文で確認した条件と、DELETE文の条件をそろえることです。
確認したものと違う条件で削除すると、想定外のデータを消してしまう可能性があります。

この記事内のSQLは、あくまで今回の環境でWP-Optimize由来と思われるTransientを確認・削除した記録です。実行する場合は、必ずバックアップを取り、自分の環境のテーブル名や削除対象を確認してから進めてください。

WP-Sweepで削除できなかった理由は断定できない

今回のTransientは、確認した限りでは期限切れになっていました。
そのため、通常であればWP-Sweepで削除されてもよさそうに見えます。

ただ、なぜ削除対象にならなかったのかは、はっきり断定できません。

考えられる理由としては、Transientの名前や形式がWP-Sweepの削除条件に合わなかったこと、削除済みプラグイン由来のデータが特殊な形で残っていたこと、あるいはキャッシュ環境の影響などが考えられます。

実際に、削除前のレコードを見た限りでは、Transient本体とtimeoutのセットが存在しているようにも見えました。
それでもWP-Sweepでは消えなかったため、今回のケースではプラグイン任せでは確認しきれない残留データがあった、という受け止め方にしています。

まとめ｜プラグイン任せにせず、DBの中身も確認する

WP-Sweepは、WordPressの不要データを整理するうえで便利なプラグインです。
リビジョンやTransientなどの件数を確認でき、通常のメンテナンスでは十分役立つ場面が多いと感じています。

ただし、今回のように、削除済みプラグイン由来のデータが残り、WP-Sweepでは削除されないケースもありました。

大切なのは、いきなり削除することではなく、まず確認することです。

  1. WP-Sweepで件数を見る
  2. phpMyAdminで実際のデータを確認する
  3. SELECT文で削除対象を確認する
  4. バックアップを取る
  5. 必要なものだけ削除する

データベースの掃除は、見えない場所を触る作業です。
だからこそ、プラグインだけに頼り切るのではなく、必要に応じて中身を確認する姿勢も大事だと感じました。

とはいえ、phpMyAdminでの削除は最終手段です。
普段はWP-Sweepのようなメンテナンス用プラグインで管理し、どうしても残るデータがある場合だけ、慎重に確認しながら対応するのが安全だと思います。

技術備忘録
  • URLをコピーしました！

コメント

コメントする

目次