...
ウェブホスティングのロゴ

WordPressのデータベースサイズを縮小：データを失うことなく賢明な対策を

具体的にどうすればいいかを紹介しよう。 データベース・サイズの削減, コンテンツを失うことなく、高速なプラグインソリューションから制御されたMySQLステップまで。これにより ロード時間, サーバーは解放され、あなたはすべての変更を完全にコントロールできる。.

中心点

テーブルに手を加える前に、私は目的を明確にし、データベースを保護し、本当に必要なクリーンアップ手順を決定する。こうすることで、リスクを回避し、メンテナンスの無駄を省き、測定可能な効果を得ることができる。以下のポイントは、的を絞った方法でプロセスを案内するものです。明確な順序、実践的なヒント、典型的な落とし穴に関するアドバイスを受けることができます。そして、最適化を安全かつ繰り返し実施できるようになります。.

  • バックアップ 第1回：完全バックアップと再生テスト
  • プラグイン を使う：WP-Optimise、WP-Sweep、Advanced Database Cleaner
  • phpMyAdminテーブルの最適化、トランジェントのクリーンアップ
  • wp_options 一目でわかるオートロードとレガシーロードのチェック
  • 自動化定期的なクリーンアップと監視作業

私は影響とリスクに応じて対策に優先順位をつけ、安全な削除候補から始め、より深い介入へとステップアップしていく。これによって ウェブサイト データはそのまま残り、データベースは予想通りスリムになる。.

WordPressデータベースはなぜ成長するのか？

日々のビジネスでは、すぐに蓄積される。 改訂, スパムコメント、ごみ箱の中の削除されたコンテンツ、期限切れのトランジェント。このようなエントリーはクエリー時間を増加させ、テーブルを肥大化させ、そして CPU-消費。特に影響を受けるのは、wp_posts（リビジョン）、wp_postmeta（メタ・バラスト）、wp_options（トランジェント、オートロード）、wp_comments（スパム、ゴミ箱）です。加えて、MySQLのテーブルには、削除を繰り返した後に発生するオーバーハングがあり、クエリが遅くなります。早い段階で増加に対処することで、リソースを節約し、ファーストバイトまでの時間を短縮し、クリーンなデータ素材を確保することができます。.

正確な診断：何が本当に成長しているのか？

削除する前に、計測する。phpMyAdminで、各テーブルのデータとインデックスサイズを表示し、上位の消費者を特定します。より正確を期すのであれば、INFORMATION_SCHEMAで概要を表示し、データの合計でソートします：

SELECT
  テーブル名
  ROUND((data_length + index_length)/1024/1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC；;

例えば、私はこのように認識している。. wp_postmeta は、製品やSEOのメタデータが多いために優位に立つ。重要：InnoDBを使用した場合、物理ファイルサイズがすぐに縮小するとは限りません；; OPTIMIZEテーブル はテーブル内のメモリを解放し、file_per_tableはファイルシステム・レベルでも解放する。開始値と目標値を文書化することで、各対策の利点を目に見えるようにした。.

バックアップ・ファースト：データのバックアップ方法

削除する前に データベース を完全に実行し、リストアをテストします。phpMyAdminでDBを選択し、エクスポートをクリックし、SQLファイルをローカルに保存します。テスト済みのバックアッププラグインは、2つ目のバックアップを作成することもできます。バックアップがすべてのテーブルと接頭辞を含んでいるかどうか、特にマルチサイトや変更されたDBでは必ずチェックします。 テーブル接頭辞. .バックアップとリストアがうまくいってから、クリーンアップを始める。.

ステージング、ロールバック、ダウンタイムの最小化

私は、サイトがアクセスしやすい状態を維持できるように、介入を計画する。そのために、私はまず、可能であれば ステージング・インスタンス, 私は最も重要なフロー（ログイン、チェックアウト、検索）をテストし、そのステップを本番システムに移します。削除の実行は主な訪問時間外にスケジューリングし、実行の直前にキャッシュを無効化し、実行後にキャッシュを空にし、エラーログをチェックする。ロールバックについては、テスト済みのDBバックアップを準備し、変更を元に戻せるよう、すべてのクエリを変更ログに記録しておく。.

日常生活でワードプレスのデータベースをクリーンアップするプラグイン

ルーティンワークの場合、私はまず WP-オプティマイズ, リビジョン、スパム、ごみ箱、トランジェント、テーブルを一度に処理してくれるからだ。インストール後、私は自動クリーンアップを有効にし、毎週実行するようにスケジュールします。必要であれば、WP-Sweepでピンバック/トラックバックを、Advanced Database Cleanerで孤児となった エントリー 特定の候補を特定するために。削除する前に、プレビューをチェックし、危険なオプションを無効にし、明確な候補だけを確認する。こうすることで、最小限の労力で顕著な効果が得られ、「wp optimise database」ルーチンをきれいに自動化できる。.

phpMyAdminでの手動最適化：コントロールの維持

もっとコントロールが必要なときは、次のように切り替える。 phpMyAdmin そして、サイズ別にテーブルをソートする。大きな候補はドロップダウンを使って最適化する。 OPTIMIZEテーブル そしてオーバーハングを減らす。私は DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%'；;. .未使用のタグは DELETE FROM wp_terms WHERE term_id NOT IN (SELECT term_id FROM wp_term_taxonomy)；;. .各ステップの後、私はウェブサイトとエラーログをチェックし、さらにクリーンアップする。 リスク 小さいままだ。.

リビジョン、スパム、ごみ箱を安全にクリーンアップ

改定は有益だが、市場を際限なく膨張させる。 wp_posts で制限しています。で制限している。 define('WP_POST_REVISIONS', 3)；; をwp-config.phpに追加し、プラグイン経由で古いリビジョンを削除します。私は定期的にスパムやゴミを掃除しています。 wp_comments 目につく。自動ドラフトも見て、重複を削除している。削除するたびに、再度テーブルの最適化を実行し、メモリを解放しています。.

wp_optionsをクリーンに保つ：オートロードとトランジェント

テーブル wp_options 特にオートロードの値が大きいと、隠れた遅延を引き起こすことが多い。私は、オートロードされたオプションの総量を測定し、すべての呼び出しでロードされる特大のエントリーを停止する。定期的に期限切れのトランジェントを削除している。その背景や典型的なロードソースについて詳しく知りたい方は、以下を参照してください。 トランジェントを理解する. .クリーンアップの後、フロントエンドとバックエンドをチェックし、次のような影響を検出する。 ロード時間 をチェックする。

簡単なクエリーで、オートロードの負荷を素早く見積もることができる： SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes'；;. .個々の異常値は SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 20；;. .私は、滅多に使わない大きな値をオートロード = ’no'に設定し、必要なときにプラグインが特別にロードするようにしている。.

ターゲットを絞ったテーブルの最適化：何が最も効果的か？

無造作にすべてを削除するのではなく、私は最大のテーブルを中心に削除する。 効果. wp_postsとwp_postmetaが最も強力で、wp_optionsとwp_commentsがそれに続く。その後、phpMyAdminでビフォーアフターを比較し、進捗を測定します。この透明性によって、リスクを最小限に抑え、次のラウンドの価値がどこにあるかを示すことができる。以下の概要では、典型的な発見と適切なアクションを分類しているので、構造的に進めることができます。.

テーブル 原因 典型的なバラスト 推奨措置 リスク
wp_posts リビジョン、カーデザイン 寄稿ごとに数十回の修正 リビジョンの制限/削除、最適化 バックアップのため低め
wp_postmeta 古いメタ・エントリー 孤児メタ・キー 孤児メタの削除、インデックスのチェック 手段、事前チェック
wp_options トランジェント、オートロード 期限切れのキャッシュデータ トランジェントの削除、オートロードの削減 低～中
wp_comments スパム、ごみ箱 レガシー問題とスパムの波 大量削除、自動設定 低い

WooCommerceとトラフィックの多いショップの特別なケース

ショップは平均を上回る数のデータレコードを作成する。 wp_postmeta (バリエーション、属性、注文のメタデータ）を入力し wp_options セッションとトランジェント定期的に期限切れのセッションやトランジェントを削除し、不具合のあるカートの保存期間を短縮し、テーマやプラグインが不必要な商品メタデータを保存していないかチェックしています。完了したジョブを早めにクリーンアップし、失敗したジョブを延々と再スケジュールしないことで、アクションスケジューラ（as_actionsなど）のテーブルを小さく保っています。大規模な販売やインポートの後に、追加ラウンドをスケジュールする。 OPTIMIZEテーブル, オーバーハングを素早く減らす。.

マルチサイト機能

ネットワークでは、バラストはすべてのブログに掛けられる。私はサイトごとに、独立したテーブルの接頭辞（例えば. wp_2_)、さらにクリーンアップ ネットワーク全体の過渡現象 に於いて _site_transient_*。. .グローバル・テーブル（例えばwp_usersやwp_usermeta）については、私は全体的に何も削除しませんが、サイト間の依存関係をチェックします。ネットワークの一貫性が保たれるように、同期や移行のウィンドウの外にクリーンアップのジョブをスケジュールします。.

MySQL WordPressの高度なチューニング手順

交通量が多いときは、次のことに注意している。 イノDB-設定とインデックス。適切に設定されたバッファプールと、頻繁にフィルタリングされるカラム（例えばwp_postmetaのmeta_key）に意味のあるインデックスを設定することで、クエリが大幅に高速化されます。クエリ・キャッシングは古いバージョンのMySQLにも存在しますが、最新のセットアップでは、アプリケーションやオブジェクト・レベルでの優れたキャッシングの方がメリットがあります。さらに、ページロードの初期速度を低下させるような特大のオートロードエントリは避けています。 オートロードオプション. .各チューニングの後、私は再び測定を行い、チューニングへの影響を判断する。 応答時間 を確認する。

指標をコントロール：試行錯誤のパターン

私は特に、典型的なフィルターが感覚的にサポートされているかどうかをチェックする。例えば wp_postmeta 指標は以下に基づいている。 (post_id) クエリーによっては (meta_key, post_id) 実証済み。について wp_options デフォルトでは オプション名; オートロード後のクエリーには、既存の (オートロード）-インデックスを使用するか、フィルターをLIMITと組み合わせます。インデックスを追加する前に、最も頻繁に使用されるクエリをシミュレートし、その実行時間を測定する。余計なインデックスや冗長なインデックスが測定可能な利益をもたらさない場合は削除します。.

WP-CLIの実際：高速でスクリプト可能なクリーンアップ

シェルアクセスが可能であれば、私は以下のようなルーチンを高速化する。 WP-CLI. .私がメンテナンス・ウィンドウで使用している例：

  • トランジェントをクリーンアップする： wp transient delete --期限切れ 必要に応じて wp transient delete --all
  • 迷惑メール/紙カゴを空にする： wp comment delete --status=spam --force, wp comment delete --status=trash --force
  • 修正を減らす： wp post list --post_type='post,page' --field=ID --post_status=publish | xargs -n100 wp post delete-revision
  • データベースを最適化する： wpデータベース最適化 でサイズをチェックする。 wp db size --tables

これらのコマンドはcronジョブやデプロイスクリプトに組み込むことができる。私はまず読み込みコマンド（リスト、カウント）を実行し、選択を確認してから削除コマンドを実行する。.

文字セット、照合順序、行フォーマット

一貫性のない文字セットは移行時のリスクを増大させ、テキスト列へのインデックスを制限する可能性がある。可能であれば utf8mb4 一貫した照合順序で（例えば. utf8mb4_unicode_ci).切り替えの前に、私はDBをバックアップし、ステージングアップデートをチェックし、制御されたステップでテーブルを変換します。InnoDBテーブルについては、現在の行フォーマット（例えば. ダイナミック)を使って、長いTEXT/VARCHARを効率的に入れ替えることができる。と組み合わせることで innodb_file_per_table=ON 提供する OPTIMIZEテーブル は、空き領域がファイルシステムに戻されることを保証する。.

自動化：希望するのではなく、清潔さを計画する

繰り返しの仕事で時間を節約している 終了. .WP-Optimizeでは、毎週クリーンアップと毎月のテーブル最適化を設定しています。加えて、システムcronは、スケジュールされたタスクがキャンセルされないように、WordPress自身のcronを確実にトリガーすることができます。wpデータベースの最適化 „のような繰り返されるアクションのために、私は主な訪問時間の外に固定時間ウィンドウを設定します。これにより、全てのステップを手動でトリガーすることなく、データベースを恒久的に無駄のない状態に保つことができる。.

モニタリングとテスト：成功を可視化する

各ラウンドの後、私は DBサイズ をphpMyAdminで開き、開発状況を記録します。Time-to-First-Byte と Largest Contentful Paint がどのように変化しているかをチェックします。wp_optionsやwp_postmetaの顕著な増加がパフォーマンスに影響を与える前に、早い段階で対処する。この記事は、恒久的にクリーンなオプションを考えるための有益な材料を提供してくれる： wp_optionsのメンテナンス. .同時に、後で決定事項を追跡できるように、日付、対策、結果を記載した変更ログを残している。.

実用的な数値と基準値

私は、最適化が停滞しないよう、明確な制限を定めている。例えばオートロードの合計を1-2MB以下に保つ；; wp_postmeta に関して wp_posts 妥当である（正当な理由なく20～50倍を超えるファクターはない）。 wp_options 伸びない。パフォーマンスに関しては、TTFB、バックエンドの検索クエリー（商品リストなど）、管理画面のロード時間を定期的に測定している。コアバリューが増加したり、テーブルが突然移動したりした場合は、一律に「すべてを削除」するのではなく、集中的な分析を開始します。.

孤児テーブルやアンインストールの残骸を系統的に削除する。

多くのプラグインはテーブルやオプションを残していく。私は接頭辞で非コア・テーブルをリストアップし、候補を集め、2段階に分けて作業を進める：まず、テーブルの名前をテスト用に変更する。. テーブルwp_altplugin_dataをwp_altplugin_data_backupにリネームします；;)し、ページを監視する。すべてが安定していれば、私はそのテーブルを永久に削除する。で wp_options 典型的なプラグインの名前空間 (オプション名 LIKE '%pluginname%')し、機能を理解したエントリーだけを削除する。については wp_usermeta そして wp_postmeta 私は、参照されているIDがまだ存在しているかどうかをチェックすることで、孤児となったキーを特定する。.

よくあるミスを避ける

私は決して削除しない バックアップ と再生テスト。wp_postmetaの大量削除は、孤児になったメタキーを分析した後、危険なものだけを実行しています。プラグインのクリーンアップは、すべてのオプションを有効にするのではなく、選択的に使用する。削除後、キャッシュをクリアし、ページセクションが予期せず失敗しないように機能をテストする。何か不明な点が残る場合は、まずステージングインスタンスで作業し、テストが成功した後にクリーンアップを本番システムに転送します。.

簡潔な要約

明確なシークエンスで、クリーン バックアップ といくつかのツールを使えば、どんなWordPressデータベースでもデータを失うことなく合理化することができます。私は、トランジェント、スパム、リビジョンなどの安全な候補から始め、テーブルを最適化し、ルールを使用して将来の成長を制限します。大規模なセットアップの場合は、phpMyAdminの手動ステップと賢明なMySQLチューニングポイントを使用します。自動化されたルーチンによって、データベースを持続的に小さく、かつ測定可能なほど高速に保つことができます。これらのガイドラインに従えば、サイズが小さくなり、サーバーの負荷が下がり、ページが明らかに速くなります。.

現在の記事