WordPressのDBが予想外にサイズが大きい場合の対処

はじめに

本ブログが利用しているWordPressで不具合があり調査した結果がDBサイズがサービスの上限を超えていたために不具合が発生していました。
DBのどのテーブルが大きいのか? 削除できるレコードがあるのか?
といったことを調べていき対処したことを記事にしました。

事象

記事の新規投稿を使用として、投稿→新規追加をしたところ編集画面が記事本文を入力するエリアが表示されない。
クイック編集で下書きを作成した後に編集可能となるがアイキャッチ画像が登録できない。

原因

WordPressのクラウドサービスを利用しています。クラウドサービスではDBサイズは上限が500MBです。
クラウドサービスのダッシュボードで確認したところDBサイズが1200MB強になっていました。
どうやらDBサイズがサービスの上限を超えていることが原因のようです。

調査

まずはDBのどのテーブルが大きいのかを調べます。次の記事を参考にして記載されているSQLを実行してみました。
MySQL 各テーブル毎に容量を確認する
結果としては、「wp_options」というテーブルが9000行かつ1200MBというサイズがありほとんどこのテーブルがDBサイズの大半ということが判明しました。
この「wp_options」をいかにスリム化できるのかが次のステップとなります。

wp_options とは

WordPressのCodex日本語版のデータベース構造に記載がありますが
「オプション設定情報を格納する」
とあります。設定情報だけで9000行になるとは思えません。もう少し検索してみると
WordPressのデータベースwp_optionsテーブルが極度に肥大した際の対策。というそのものずばりのページがヒットしました。
どうやら設定情報以外にプラグインなどが一時情報を置くエリアとしても使われているようです。
こちらの記事ではジェットパックが利用しているjpsq_syncを含んだレコードが主となる原因だったようです。しかし、私の場合は1行程度しかヒットしませんでした。
むしろ「_transient」を含んだレコードが8000行以上あったのでこちらが問題だと判断しました。

レコードの内容を見ていると「_transient」以外に「_amp」も含んだレコードが大半であることが判明。
どうやらAMPプラグインが吐き出したレコードを放置していることが原因かと思われます。

対処法

クラウドサービスにはphpMyadminが用意されています。このツールを使ってDB上で

SELECT * FROM wp_options WHERE option_name like ‘%_transient%’ AND option_name LIKE “%amp%”;

を実行してヒットした行を削除するということで対処しました。DELETEを実行させて一気に削除もできますがちょっと怖かったので削除対象レコードをエキスポートしてから削除して動作に問題ないことを確認するということをしました。

削除した結果DBサイズは約60MB程度になり記事の新規追加が正常に行えるようになりました。

コメント

タイトルとURLをコピーしました