WordPress 不要なリビジョンを削除することでデータベースを軽くする

僕はブログに書こうとするネタを思いついたら、ひとまずEvernoteにメモします。

 

その日の寝る前に、WordPressに非公開の状態で記事の骨子を書き込んでおき、後日、時間ができたらWordPressの投稿画面のまま本格的に記事を作成しています。

 

ですが、このやり方だと、

 

リビジョンがやたら増える

 

という問題が発生します。

「ん?リビジョンが増えるのってなんか問題あるの?」

 

と思われる方もいらっしゃると思いますが、ご指摘どおり、リビジョン自体は残っていることに問題なく、むしろ途中保存してなかったときなどには重宝します。

 

ですが、記事データを何世代にもわたって保存することになるので、データ容量を圧迫するという問題が起きます。

 

本日は、この問題を解消するプラグインを紹介したいと思います。

 

リビジョンが増えることによる問題

実は、リビジョンはテキストデータのみで、利用している画像データなどは保持しません。

 

なので、いくら増えるといってもテキストデータだけなので、そんなに問題視することはないと思われがちですが、WordPressはデータベースを利用したシステムなので、データベースのレコードがじゃんじゃん増えることを意味しています。

 

WordPressはデータベースへのアクセスが非常に多いため、記事が増えれば増えるほど、MySQLの動作が重くなり、それに伴い表示速度に遅くなります。
また、一般的なレンタルサーバを利用している場合は、データベースのアクセスが一定以上超えるとアクセス制限をするところもあります。

 

実際、僕が借りているXserverにて展開しているサイトに月間100万PVを超えているWordPressのサービスがあります。

 

このサイトは、幾度かXserverから負荷がかかっている旨のアラートを受け、一時的にMySQLの接続制限をされたことがあります。

(この話は、Xserverで負荷軽減対策の記事を参考にしてもらえればと思います)

 

幸いにも、本サイトは、幸いにもあまり閲覧者がいないので心配はいらないのですが、。。。(悲)

 

対応方針

不要なリビジョンは削除。

また、不要なレコードも削除し、データベースのオーバーヘッドを解消させる。

 

※オーバーヘッドとは、データの「更新」「追加」「削除」などに伴い発生する「冗長化部分(無駄なデータ領域)」です。
これらオーバーヘッドを削除する処理が「テーブルの最適化」です。

 

データベースに更新が入るため、作業前に必ずバックアップを取ってください。

 

実装方法

では、プラグインの説明をします。

 

管理画面から、プラグイン新規追加で「Better Delete Revision」を検索し、「今すぐインストール」ボタンをクリックします。

410-1

 

インストールが完了したら、「プラグインを有効化」します。

410-2

 

プラグインを有効化すると、左メニューのプラグインの中に「Better Delete Revision」が表示されますので、こちらをクリックします。

410-3

 

Better Delete Revision Manager の画面が表示されます。

 

まず、どのくらいリビジョンがあるのかを見てみましょう。

なにやら英語で記述がされていますが、気にせず、「Check Revision Posts」ボタンをクリックします。

410-4

 

すると、保存されているリビジョンの一覧が表示されます。

確認し、消したらまずいものがなければ「Yes , I would like to delete them! (A Total Of XXX)」ボタンをクリックします。

410-5

 

以下の画面が表示されたら、リビジョンの削除は完了です。

410-6

これだと、リビジョンの管理に使っているデータ容量はなくなりますが、データベースのほうにはデータが残ってしまっています。

そこで、データベースを最適化します。

 

再度、左メニュープラグインの「Better Delete Revision」にアクセスし、今度は「Optimize Your Database」ボタンをクリックします。

410-7

 

すると、本サイトで利用しているデータベースのテーブル一覧が表示されます。

「Optimize WordPress Database」ボタンをクリックします。

410-8

もし、赤字で表示されていたらシステム的に負荷がかかりすぎてますよー、という合図です)

 

完了画面が表示されたら秋涼です。

410-9

 

実行結果

本サイトでいくつかリビジョンがたまっていたので、実行前後を調べてみました。

 

67個ほどリビジョンがたまっています。

これの実行前と後のデータベースの容量を見てみます。

410-10

 

なお、データベースの使用容量を調べるときは、以下のコマンドで取得できます。

select table_schema, sum(data_length+index_length) /1024 /1024 as MB from information_schema.tables where table_schema = ‘databaseName’;

 

実行前

410-11

 

実行後

410-12

 

ただのテキストデータなので、あんまり効果がないと思っていましたが、想像以上に効果がありました。

データベースの不要なレコードがなくなれば、その分selectの実行結果も早くなりますので、結果としてデータベースの負荷軽減&高速化に寄与できていると言えます。

 

もうこのプラグインを使い始めてから2年くらい経ちますが、気が付いたときにボタンをクリックするだけなので、運用上、わずらわしいと感じることもありません。

 

個人的に激しくオススメさせていただきます。

 

Author:yukio iizuka
プロフィール画像
フリーランスとしてUX視点で業務支援しています。 HCD-Net認定 人間中心設計専門家 LEGO®︎ SERIOUS PLAY®︎ メソッドと教材活用トレーニング修了認定ファシリテーター Hi-Standard好きです。
http://yukioiizuka.com
mislead
MISLEADの記事に共感いただけましたら
いいねをお願いします。

コメント一覧

  • ジンジャー

    MySQLは100万件のレコードがあっても余裕なDBなので、
    たかだかリビジョン数が1000とか10000とかあっても
    特別遅くなるということはありえないと思いますが。
    インデックスを適切に張ってないとかでない限り。

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



       

© yukio iizuka All Rights Reserved...