先日、記事にもしましたがWP-Optimizeを削除しました。
使用目的がDBの掃除のみだったので、自分にはWP-Optimizeのキャッシュ設定などは不要だったからです。
そして代替品としてWP-Sweepを使う事にしました。
WP-Sweepを使ってリビジョンやら削除済みコメント、Transientなどのレコード数を把握できますが、はたしてDBで表示される数はをそれらと一致しているのでしょうか。
WP-Sweepで把握している不要レコード（ゴミ）の数
以前使い終わった後に無効化していたので、ささっと有効化します。
とくに設定することなく画面を開くと各レコードが表示されるので確認します。
リビジョンの数は50でした。それからもう一つ気になっているレコードに注目します。
Transientは33でした。
次はphpMyAdminを使ってDBの中を覗いて行きます。
DBの実際の数
ログインをしたら対象のDB上でSQLタブを開いてクエリを入力します。
SELECT * FROM wp_posts WHERE post_type = 'revision';これを入力するとリビジョンの数を出してくれます。
合計が50と表示されています。WP-Sweepが出したレコード数と一致しています。
SELECT * FROM wp_options WHERE option_name LIKE '_transient_%';次はTransientの番です。これをリビジョンと同じく、同じ場所に入力します。
合計が33と表示されています。こちらもWP-Sweepが出したレコード数と一致しています。
これでWP-Sweepが示すレコード数がDBの実数値と同じだと証明できました。
しかし、ここで気になる物を目にしました。それはTransient（一時データ）の内容です。
これは削除したプラグイン：WP-OptimizeのTransientです。
Transientとは一時的なキャッシュデータです。プラグインを削除する際に設定データを削除したのですが、こうやって残っていたみたいです。
既に削除済の不要なレコードなので、WP-Sweepを使って綺麗に削除します。
残り続ける削除したプラグインの残骸
phpMyAdminから直接レコードを削除することも可能ですが、せっかく導入したWP-Sweepを使って、まずは安全に一括削除を試みます。
※レコードの削除前は必ずバックアップを取ってください。
少し余裕をかましていたのですが、ここで事態が一変しました。リビジョンの削除は正常に完了したものの、WP-OptimizeのTransientがどうしても削除できないのです。
何度実行しても、最初に見た「33」という数字から全く変わりません。
「本当に消えていないのか？」を確認するため、改めてphpMyAdminでDBの中を覗き、再びTransientの数を数えるクエリを入力します。
そこで出た結果は、やはり「33」。WP-Sweepの表示は正しかったのです。つまり、削除命令を出したにもかかわらず、居座り続けているということになります。
ここで、なぜ削除できなかったのか、仮説を立てて整理してみます。
- WP-Sweepの仕様: WP-Sweepが削除するのは、主に「期限切れ（Expired）」のTransientです。使用目的（有効期限）があるものは削除対象外となります。
- 有効期限の壁: まだ期限が切れておらず、システム上「有効なデータ」と判定されている「消せないゴミ」である可能性。
- キャッシュの影響: オブジェクトキャッシュ（APCu Manager）の影響で、WP-Sweepが「メモリ上の活きたデータ」と誤認し、掃除の必要なしと判断している可能性。
Transientに与えられた有効期限
コンピュータにとっての「時間」はただの数字
これを聞くと「えっ！？」と思いますが、人間は「2026年3月31日」と言えば分かりますが、データベースなどのコンピュータの世界では、計算を楽にするために「1970年1月1日から、今この瞬間まで何秒経ったか」という膨大な秒数だけで時間を管理しています。
「謎の数字」の正体を暴くツール
phpMyAdminに並ぶ謎の数字。それは、コンピュータが話す『秒数』という名の暗号です。
そこで、とあるサイトにその数字を放り込むと、「それは2026年3月31日のことですよ」と、人間にわかる形に一瞬で直してくれます。
そのサイトが Epoch Converter です。
Transientに与えられた有効期限を調べる
さっそく有効期限を調べます。
対象のTransientの秒数は1774971412です。この数字は先程のWP-OptimizeのTransient画像に表示されています。
そして調べた結果がこちらになります。
翻訳画面なので少し言葉がおかしい所がありますが、簡単に説明すると以下のとおりになります。
- 対象Transientの有効期限（2026年3月31日）日本時間で2026年4月1日の深夜0時36分
- この記事を作成している日から四日前に切れている
つまり、このレコードは四日も前に期限が切れているにも関わらず、WP-Sweepをかいくぐり、今なおDBに居座り続ける…ゴミです。
不要なレコードの削除とWP-Sweepによる確認
不要となれば後は削除するだけです。
一応ではありますが、ここでもレコード数が一致するのかを確認の為に手動で対象Transientに表示っされている削除を押します。
ここで万が一何かあっても、バックアップを取ってあるからすぐに復旧できます。
そして一件手動で削除した後にWP-Sweepの画面でレコード数を確認します。
33だったのが一件分が減って32になってます。
あとはもう何も迷う事はありません。DBに居座っている使っていないプラグイン：WP-OptimizeのTransientをクエリによる一斉削除をするだけです。
DELETE FROM wp_options WHERE option_name LIKE '_transient_wpo_%';※削除などのクエリを入力する際は必ずバックアップを取ってからにしてください。
※上記のクエリはWP-OptimizeのTransientを削除するだけのものです。
残っていたWP-OptimizeのTransientは5件でした。これで、WP-Sweepをすり抜けていた『WPO由来のデータ』は全て一掃できたことになります。あとはWP-Sweepの画面で最終確認です。
最初に確認した時は33で、１件手動削除、５件がクエリで削除で残り27でDBとの数が一致しています。
何故WP-Sweepで期限切れレコードは削除できなかったのか
期限が切れている（4日前）ということは、本来なら WP-Sweepで掃除できるはず。
1.Transientの「対（ペア）」が片方だけ消えていた可能性
- 通常、Transientは
_transient_名前と_transient_timeout_名前の2つがセットです。 - WP-Optimizeを消した際、片方のレコードだけが中途半端に残ってしまい、WP-Sweepが「不完全なデータ」として掃除対象から漏らしてしまった（＝ゴミと認識できなかった）可能性。
これは違うかもしれない。削除する前のレコードを確認した所、セットとなるレコードは存在していた。
2.WP-Sweepの「掃除の基準」がもっと前だった
- WP-Sweepが「かなり古いもの」しか消さない設定になっているか、あるいは今回の「wpo」のデータ形式が特殊で、WP-Sweepの検索に引っかからなかったのかもしれません。
これはありえます。実際に、有効期限が3日前に切れているレコードが、まだいくつか残っているのを確認しました。
結論：プラグインは万能ではない。最後は自分の「目」でDBを仕留める
個人的な体感として、基本はWP-Sweepで最適化してあげるだけでもWebサイトは十分に快適になります。
しかし、今回のように「4日前に期限が切れているのに居座り続けるゴミ」は、どれだけ高性能なプラグインを使っても、その仕様の隙間を縫ってDBに潜み続けます。
こうした「漏れ」が蓄積されることが、将来的なDBの肥大化やパフォーマンス低下を招くのでしょう。
「最後は自分の手と目で確認する」
ツールに頼り切るのではなく、時にはこうしてDBの裏側に潜り、自力で不要レコードを仕留めること。それこそが、サイトを真の意味で「清潔」に保つために必要なメンテナンスなのだと、改めて痛感しました。
コメント