SQLiteだと自動で消えないWordPressのゴミデータを削除

Apacheエラーログ対策のため、WP Crontrolで「delete_expired_transients」の自動実行を停止してみたが、根本的な解決にはなっていないので調べてみた。
エラーの内容をよく見ると、同じような構文で二種類あった。

DELETE a, b FROM wp_options a, wp_options b
WHERE a.option_name LIKE ‘_transient_%’
AND a.option_name NOT LIKE ‘_transient_timeout_%’
AND b.option_name = CONCAT( ‘_transient_timeout_‘, SUBSTRING( a.option_name, 12 ) )
AND b.option_value < [良くわからない数字]

DELETE a, b FROM wp_options a, wp_options b
WHERE a.option_name LIKE ‘_site_transient_%’
AND a.option_name NOT LIKE ‘_site_transient_timeout_%’
ND b.option_name = CONCAT( ‘_site_transient_timeout_’, SUBSTRING( a.option_name, 17 ) )
AND b.option_value < [良くわからない数字]

このデータは、WordPressに備わっている「Transit API」によるものらしい。高速化のための簡易なキャッシュ機能で、有効期限付きで一時保存されるデータのようだ。[良くわからない数字]については、やっぱりUNIX時間だった。「delete_expired_transients」は「Transit API」で生成されたキャッシュデータについて期限切れになったものを一日一回自動削除しているようだ。

理由が分かれば簡単だが、WordPress本体のPHPを改修するのはバージョンアップの度に面倒だし、外部から自分で作った怪しげなDELETE文を毎日自動実行するのも、何だかちょっと気が引けた。ほったらかしにしても問題無さそうなので、メンテナンス作業の時にでも確認しながら手動で実行することにする。

「_transient_」で始まるデータと、「_site_transient_」については全て一時データのようだ。無くても問題ない。いちいち削除範囲のUNIX時間を入力するのも面倒だ。期限切れのデータのみを消すのでは無く、有効期間中でも全部を強制的に期限切れとして考えてしまえば、とても簡単だ。必要ならWordPressが自動的に再生成してくれるはずだ。その方が個人的には気持ちが良い。
ということで、結果が分かりやすい以下のSQLを自宅のPCで実行することとした。

DELETE FROM wp_options WHERE option_name LIKE '$_transient$_%' ESCAPE '$';
DELETE FROM wp_options WHERE option_name LIKE '$_site$_transient$_%' ESCAPE '$';
COMMIT;
VACUUM;

これできれいさっぱりキャッシュデータは削除される。最後の「VACUUM」は、最適化のおまじないだ。物理的に不要なデータを全て削除して、ファイルサイズを小さくしてくれる。
実際に実行すると。。。