【WordPress】サイトを高速化するためにデータベースの最適化をして大幅に容量を削減できた方法

WordPressで扱う様々なデータを保存しておくのに必要不可欠なデータベースですが、普段WordPressを使ってブログを書いたり作業をしたりしていたとしてもデータベースに格納されるデータを気にしたりすることはまずないんですよね。

自分が管理しているサイトでやけに表示が遅いなと思うサイトがあり高速化のために試行錯誤していたんですが、あるときデータベースの肥大化でパフォーマンスが落ちているのでは？と思ったため、データベースの最適化をしてサイトの高速化を試みてみました！

---

---

 

WordPressで使用しているデータベース容量の調査

まずは、WordPressで使用しているデータベース容量の調査をしました。と言っても、サイトの高速化のためにプラグインの見直しや無駄なデータがないかなどを調べているときに蓄積されているリビジョン(過去の記事を復元するためのデータ)を削除しようと思いました。

 

Optimize Database after Deleting Revisionsというプラグインを導入してリビジョンの削除及び今後のリビジョン管理をしたんですが、そのときにデータベース最適化も同時に行ってくれるプラグインのためデータベース最適化をしたところデータベース最適化後のデータベース容量がやけに多いな・・・と気づきました。

 

以下が、自分が管理している記事数約250ほどのサイト(ブログ)のデータベース容量です。

 

 

上の赤枠で囲った部分がやけに多いな・・・と思えるテーブルですね。これらのテーブルについて容量の削減を考えてみることにしました。

 

 

WordPressのテーブルごとの最適化

テーブルの最適化と自分が言っているものは、テーブルのオーバーヘッドの最適化のことで、オーバーヘッドとはデータベースのテーブルにデータを入力したり削除したりすることによって、カラムが虫食い状態になるためにこの状態を解消するものです。

 

Windowsでいうところのデフラグみたいなもので、オーバーヘッドが多くなるとデータベースの容量が肥大化して挙動が重くなり、クエリが遅くなってそれがサイトの表示が遅くなり原因となるためにオーバーヘッドを取り除く必要があります。

 

まずは、テーブルの最適化のためにデータベースにアクセスする必要があるため、自分の場合はレンタルサーバーからphpMyAdminを用いてアクセスしました。

 

 

phpMyAdminからデータベースにアクセスしてWordPressのテーブルがずらーっと表示されました。

 

 

なお、WordPressのデータベース構造については、以下のWordPress Codexに詳しく書いてあります。

参考: WordPress Codex 日本語版 – データベース構造-

 

wp_blc_links

プラグイン「Broken Link Checker」で使用しているテーブルです。記事を書いているうちに昔の記事でリンク切れするものも出てくるために「Broken Link Checker」でリンク切れの確認をしています。

しかし、しばらくリンク切れの修正を行っておりませんでした・・・。このテーブルのデータはリンク切れの修正を行うと削除されるのかログとして残ったままなのかはまだ試していないためにわからないんですが、リンク切れの修正を済ませた際に確認してまた追記します。

一応、テーブルの最適化は行いましたがやはり何も対処していないため4MB⇒4MBと、容量は変わりませんでした。

 

wp_commentmeta

デフォルトで用意されているWordpressのテーブルです。コメントシステム等々の情報や、ゴミ箱に移動した時のステータスなどのデータが入っています。

で、このテーブルの容量が146MBもあったんですが、何でこんなに容量を使っている？というところで調べてみると、原因はプラグイン「Akismet」のスパムのログが残っているものでした。

 

プラグイン「Akismet」はスパム対策としてほぼ必須と言えるプラグインでほとんどの方が使っているとみられますが、以下のようにスパムコメントが多いサイトであったため「Akismet」のスパムのログがかなりデータベースに蓄積されていたようです。

 

 

そのため、「Akismet」のスパムのログデータだけ削除したかったので以下のSQLコマンドにより削除を行いました。

 

削除前にまずはテーブル内を検索して確認をします。

 

meta_keyというカラムの値にakismetという文字列が含む列を含むデータを抽出すると、「Akismet」のスパムのログデータを抽出できます。

SELECT * FROM `wp1_commentmeta` WHERE `meta_key` LIKE "%akismet%"

 

テーブルを検索して結果が出たことを確認し、削除します。

DELETE FROM `wp1_commentmeta` WHERE `meta_key` LIKE "%akismet%"

 

テーブルの最適化をします。

 

 

phpMyAdminだと、該当のテーブルにチェックを入れて、下にあるタブから簡単に操作ができるのでここからテーブルの最適化をしました。

 

コマンドだと以下ですね。

OPTIMIZE TABLE `wp1_commentmeta`

不要なカラムの「Akismet」のスパムのログデータを削除して最適化した結果、テーブルの容量を以下のように大幅に削減できました！

 

146MB⇒48KB!!

 

wp_commentmetaテーブルの中身はやはり「Akismet」のスパムのログデータで埋め尽くされていたようでしたねw

 

wp_options

wp_optionsテーブルは管理画面の「設定」で設定したオプション設定やプラグインの設定情報が格納されています。

 

過去に使わなくなりアンインストールしたプラグインのゴミが残っていそうです。

データを見てみると、テーマの設定情報なども格納されていました。

 

データを見て過去に使わなくなりアンインストールしたプラグインのデータの残骸を見つければ削除してもいいだろうとは思われましたが・・・それほど容量を逼迫しているとは見られなかったため、テーブルの最適化だけ行い、4.4MB⇒1.6MBに容量を削減できました！

 

割と色々なプラグインを試してみてはアンインストールをやっていたため、それなりにオーバーヘッドがあったようですね。

 

wp_postmeta

wp_postmetaテーブルにはメタデータという各投稿記事特有の情報が格納されており、カスタムフィールドや各投稿に情報や設定を付加するようなプラグインが、その情報を格納することもあります。

 

このテーブル内のデータの値を見てみましたが、投稿記事に関わるとみられるものが多くいままでに使った何らかのプラグインによるゴミが含まれている可能性はありましたが、特に容量を逼迫するものがあるとは思われなかったために今回はデータには手を出さないことにしました。

 

テーブルの最適化は行い、10.2MB⇒7.5MBに容量を削減できました！

 

wp_posts

wp_postsテーブルは投稿記事や固定ページのデータなどが入っていますね。

投稿記事や固定ページのデータなので、データベース上では直接削除できそうなデータはないでしょうね。(過去の不要な記事の削除は別途考える必要があるが)

 

ただ、105.7MBと結構容量が多く投稿記事と固定ページを足しても約300ページほどなので何でそんなに容量を使っていると言えば・・・リビジョンですね。

ちょっと修正しただけでも直ぐに下書き保存してリビジョンが結構溜まっており、Optimize Database after Deleting Revisionsというプラグインを使ってリビジョンを過去の3つまでとしてそれ以前のリビジョンは消しました。

 

そのリビジョンを消したことによるオーバーヘッドが残っていたようです。

テーブルの最適化を行い、105.7MB⇒24MBに容量を削減できました！

リビジョン管理は重要ですね！

 

データベースの最適化後の容量

データベースの最適化をしたことにより以下のように大幅に容量を削減できました！

 

311.407MB⇒39.361MB!!

 

かなりスリムになりましたね！まさか10分の1程度まで削れるとは思わなかったですね・・・。

 

ちなみに、Google Developers の PageSpeed Insightsでサーバーの応答時間をデータベースの最適化前と後で比べてみたところ、約3秒弱⇒約2秒弱とサーバのレスポンス結構影響があったようで、サイトの高速化に繋がりました！(これでもまだまだ遅いですが・・・。)

 

また、TONOSTのサイトでも同様にデータベースの最適化を行い、35.523MB⇒16.039MBに容量を削減できました！

 

あとがき

表面的には見えないゴミって結構あるもんですね。データベースの容量が肥大化していくと知らず知らずのうちに容量オーバーでWordPressの更新すらもできなくなったりもすることもあり、サイトの表示速度(サーバのレスポンスの速さ)にも結構影響を及ぼすので定期的に最適化(半年とか1年とか)が必要ですね！

 
 

---

---