月100記事でも落ちない！Xserverでデータベース最適化する方法

ワードプレス
  1. 1. はじめに｜「記事は増えるのに表示は遅くならない」サイトを作る
    1. 1-1 ブログが重くなる典型パターン
    2. 1-2 Xserver × WordPress の強みを活かす
    3. 1-3 ゴールと全体像
  2. 2. 基礎理解｜WordPress × Xserver のデータベース構造
    1. 2-1 MariaDB と InnoDB の特徴
    2. 2-2 主要テーブル早見表
    3. 2-3 よく詰まる３つの箇所
  3. 3. 現状把握｜遅延を数値化する３つの計測ツール
    1. 3-1 Query Monitor プラグイン
    2. 3-2 phpMyAdmin で EXPLAIN
    3. 3-3 Xserver リソースグラフ
  4. 4. 投稿数急増時に効く“３大メンテナンス”
    1. 4-1 投稿リビジョン削除
    2. 4-2 ゴミ箱・自動下書きの定期パージ
    3. 4-3 トランジェントのクリーンアップ
  5. 5. 必須プラグイン設定ガイド
    1. 5-1 WP-Optimize（定番の“掃除”オールインワン）
    2. 5-2 Advanced Database Cleaner（細かく選べる掃除屋）
    3. 5-3 競合させないコツ
  6. 6. Xserverサーバーパネルで出来る高速化４選
  7. 7. インデックス最適化｜クエリを最大10倍速くする実例
    1. 7-1 postmeta 肥大化を抑える
    2. 7-2 autoloaded options を洗う
    3. 7-3 安全に操作する３ステップ
  8. 8. Redis Object Cache 導入ステップ
    1. 8-1 サーバーパネル側の有効化
    2. 8-2 WordPress プラグイン設定
    3. 8-3 ベンチマーク確認
  9. 9. マルチサイト／複数 DB 分割の拡張プラン
    1. 9-1 サブドメインごと DB を分けるメリット
    2. 9-2 DB 接続プール（読み書き分離）のアイデア
  10. 10. 実践チューニング事例３選
  11. 11. 自動化｜月次・週次メンテバッチ
    1. 11-1 WP-CLI スクリプト例（週次）
    2. 11-2 Slack 通知（失敗検知）
  12. 12. トラブルシューティング（代表 5 パターン）
  13. 13. セキュリティと高速化を両立させるポイント
  14. 14. よくある質問
  15. 15. 用語集
  16. 16. まとめ｜増えても速いサイトを維持する３大原則
  17. 17. まとめ

1. はじめに｜「記事は増えるのに表示は遅くならない」サイトを作る

1-1 ブログが重くなる典型パターン

  • 投稿一覧が 1,000 本を超える
  • サムネイルや広告を呼ぶ postmeta が爆発的に増殖
  • wp-cron やバックアップ系プラグインが深夜に大量クエリ

結果──管理画面が 500 ms → 3 秒、フロントも TTFB（最初の応答） が 1 秒を超え、読者が離脱しやすくなります。

1-2 Xserver × WordPress の強みを活かす

Xserver はエンジン側で MariaDB + SSD RAID を採用しており、ライトユーザーなら無調整でも速いのが特徴です。ただし 月100記事ペース で書き足すと、デフォルト設定だけではいずれ限界が来ます。

本記事は「難しい SQL を覚えなくても、クリック操作とコピペで改善できる」ことを最優先に構成しています。

1-3 ゴールと全体像

  • 平均 TTFB 1 秒未満 をキープ
  • スロークエリ 0 本 を目標に週次で自動監視
  • 手順は 「計測 → 掃除 → キャッシュ → 拡張」 の４段階
エックスサーバーに申し込む

2. 基礎理解｜WordPress × Xserver のデータベース構造

2-1 MariaDB と InnoDB の特徴

項目概要なぜ気にする？
MariaDB 10.xMySQL 互換。Xserver は最新 10 系JSON 型や仮想列が使える
InnoDBデフォルトのストレージエンジン行ロック＆自動リカバリーで安全
バッファプールよく使うデータをメモリに保持アクセスが多いと不足→遅延

Xserver ではバッファサイズ調整は管理画面で不要。テーブル設計とクエリ数を減らす ことが実務的です。

2-2 主要テーブル早見表

テーブル主な内容ボトルネック要因
wp_posts記事本文・タイトル投稿数が直接増える
wp_postmetaカスタムフィールド広告・プラグインが大量書き込み
wp_optionsサイト設定・キャッシュオートロードで肥大
wp_commentsコメントスパム爆撃で急肥大

注意：wp_ はプリフィックス例。実サイトに合わせて読み替えてください。

2-3 よく詰まる３つの箇所

  1. postmeta の全件走査
  2. autoload=’yes’ の options を毎リクエスト読込
  3. 同期 WP-Cron がアクセス時に発火 → ピーク帯で遅延

3. 現状把握｜遅延を数値化する３つの計測ツール

3-1 Query Monitor プラグイン

  1. インストール → 有効化
  2. 管理バーに 「Queries ×× ms」 が出現
  3. 遅い順に並べ「0.1 秒以上」「重複 10 回以上」を赤字で確認

チェックポイント

  • postmeta に LIKE 検索が出ていないか
  • SELECT *（全カラム取得）が頻発していないか

3-2 phpMyAdmin で EXPLAIN

  1. サーバーパネル → phpMyAdmin → 対象DB
  2. 「SQL」タブ → 遅いクエリを貼り EXPLAIN
  3. type 列が ALL（全件走査）ならインデックス未使用

3-3 Xserver リソースグラフ

  • インフォパネル → サーバー利用状況
  • DB CPU・IO Wait が 50 % を何度も超える日は要チューニング
  • グラフを CSV で保存し、最適化後に再計測するのが確実です

4. 投稿数急増時に効く“３大メンテナンス”

4-1 投稿リビジョン削除

WordPress は記事を更新するたびに リビジョン を無制限保存します。

  • wp_posts に 5,000 記事 → リビジョンで 30,000 行超もザラ
  • 解決：wp-config.php に１行追記
phpコピーする編集するdefine('WP_POST_REVISIONS', 5); // 最新5件だけ保持

既存の膨大なリビジョンは WP-CLI かプラグインで一括削除可。

bashコピーする編集するwp revisions clean --before-date=30days

4-2 ゴミ箱・自動下書きの定期パージ

  • wp_posts の post_status = 'trash' や auto-draft が残る
  • 30 日以上前を cron で削除
bashコピーする編集するwp post delete $(wp post list --post_status=trash --format=ids)

4-3 トランジェントのクリーンアップ

キャッシュ系プラグインが wp_options に transient を量産します。

  • Advanced Database Cleaner で「期限切れトランジェント」を選択 → 週1自動削除
  • オートロード肥大を防ぎ、メモリヒット率が向上

5. 必須プラグイン設定ガイド

ポイント：プラグインは「入れただけ」では速くなりません。正しいチェックボックスを ON にすることで、本領を発揮します。

5-1 WP-Optimize（定番の“掃除”オールインワン）

  1. インストール → 有効化
  2. 左メニュー ▶ WP-Optimize ▶ 「データベース」
  3. 下表どおりにチェックを入れて「最適化を実行」
項目（日本語表示）目的備考
リビジョンをクリーン不要な履歴を削除直近 5 件残したい場合はオフ
自動下書きをクリーン下書きゴミ掃除10 日に 1 回で十分
ゴミ箱を空に投稿ゴミ箱を削除30 日残す場合はオフ
未承認コメントをクリーンスパム溜まり防止Akismet 併用なら月 1
一時オプションをクリーントランジェント削除必ず ON

スケジュール
画面下部「自動最適化」→ 週1・深夜 2:30 を推奨。

5-2 Advanced Database Cleaner（細かく選べる掃除屋）

  1. 「設定 ▶ WPデータベースクリーン」
  2. タブ【オプション】 → autoload = yes かつ 「サイズ 500 KB 以上」を目視
  3. 不要キャッシュ（多くはプラグイン名が分かる）だけチェック →「Delete」

注意

  • 誤って削除するとプラグインが初期化されることがあるため、必ずバックアップ後に実行。

5-3 競合させないコツ

  • 「掃除系」は 1 つだけ に絞る
  • キャッシュ系（WP Rocket、LiteSpeed Cache 等）と掃除系を混在させる場合は、掃除のあとにキャッシュを全部削除しておくと不整合が出ません。

6. Xserverサーバーパネルで出来る高速化４選

手順操作効果所要時間
① MySQL バージョン確認サーバーパネル ▶ MySQL設定最新10系は高速JSON関数対応1 分
② PHP LSAPI+OPcachePHP Ver.切替 ▶ ハンドラ「LSAPI」& OPcache ON動的処理をメモリに保持2 分
③ Xアクセラレータ Ver.2高速化 ▶ Xアクセラレータ[Ver.2]ページ全体をキャッシュ1 分
④ wp-cron をサーバーcronへcrontab設定 ▶ */15 * * * * php /home/アカウント/public_html/wp-cron.phpピーク時DB負荷を回避5 分

手順④の詳しい方法

  1. wp-config.php 最下部に phpコピーする編集するdefine('DISABLE_WP_CRON', true);
  2. サーバーパネル →「Cron設定」→15 分間隔で php /home/ユーザ名/ドメイン/wp-cron.php を登録

→ 投稿閲覧時に wp-cron が走らなくなるため、ピーク帯のCPUスパイクが激減します。

エックスサーバーに申し込む

7. インデックス最適化｜クエリを最大10倍速くする実例

7-1 postmeta 肥大化を抑える

a. 不要メタ削除

sqlコピーする編集するDELETE FROM wp_postmeta
WHERE meta_key IN ('_edit_lock','_edit_last')
  AND post_id IN (SELECT ID FROM wp_posts WHERE post_status = 'publish')
  AND meta_id < (SELECT MAX(meta_id)-10000 FROM wp_postmeta);
  • 編集ロック情報は古いものが無意味。

b. カスタムインデックス追加
phpMyAdmin ▶ SQL タブ

sqlコピーする編集するALTER TABLE wp_postmeta
ADD INDEX meta_key_val (meta_key(191),meta_value(191));

Elementor や広告系プラグインで meta_key='views' などを頻繁に検索する場合に 全件走査→数ミリ秒へ短縮 できます。

7-2 autoloaded options を洗う

  1. phpMyAdmin ▶ SQL
sqlコピーする編集するSELECT option_name, LENGTH(option_value) AS size_kb
FROM wp_options
WHERE autoload='yes'
ORDER BY size_kb DESC
LIMIT 20;
  1. 上位に 1 MB 超があれば、そのプラグイン設定でキャッシュ期間や保存量を減らす。
  2. どうしても不要なら
sqlコピーする編集するUPDATE wp_options SET autoload='no' WHERE option_name='不要オプション名';

7-3 安全に操作する３ステップ

  1. フルバックアップ（サーバーパネル「バックアップ」）
  2. phpMyAdmin 右上 ▶ 「エクスポート」で options と postmeta だけ別に保存
  3. SQL 実行後、サイトを 3 分ほど触り エラーが出ないか手動確認

8. Redis Object Cache 導入ステップ

ねらい：データベースへの同じ問い合わせを “毎回” 走らせず、結果をメモリに置いて一瞬で返す仕組みを足します。Xserver では無料で使えます。

8-1 サーバーパネル側の有効化

  1. サーバーパネル →「Redis」
  2. 「有効にする」をクリック → ポート番号（通常 6379）が表示されれば完了
  3. 5 分ほど待つと Redis プロセスが立ち上がります

8-2 WordPress プラグイン設定

  1. **「Redis Object Cache」**をインストール → 有効化
  2. 「設定 → Redis」
    • Status が Not Connected と出る → 「Enable Object Cache」ボタンをクリック
    • Connected: True / Status: Connected になれば OK
  3. 「Drop-in」欄が advanced-cache.php に変わっていることを確認

8-3 ベンチマーク確認

  • Query Monitor ▶ 「Environment」→ Object Cache (Hits / Miss)
  • ヒット率が 70 % を超えると DB クエリ数が 1/3〜1/5 に減少
  • 1 週間ほど運用し、キャッシュが効き過ぎて更新が出ない場合は「設定 → Redis → Flush Cache」で手動クリア

9. マルチサイト／複数 DB 分割の拡張プラン

9-1 サブドメインごと DB を分けるメリット

分割しない分割する
管理は楽だがテーブルが巨大化テーブル数が抑えられスロークエリ減
バックアップが重いサイト単位でバックアップ・復元が迅速

実装例

  1. 新ドメイン news.example.com 用にサーバーパネルで MySQL を新規作成
  2. WordPress マルチサイトをサブドメイン型で構築
  3. wp-config.php に phpコピーする編集するdefine('MULTISITE', true); define('DB_NAME_NEWS','news_db');
  4. wp-blog-header.php で blog_id を判定し、$wpdb を動的に切り替える簡易スニペットを追加

9-2 DB 接続プール（読み書き分離）のアイデア

PV が月 300 万を超えたら 読み取り専用レプリカ を Xserver ビジネスプランで追加し、

  • 読み取り：レプリカ
  • 書き込み：プライマリ
    に分けるとピーク帯でも落ちにくくなります。実装は WordPress プラグイン HyperDB が手軽です。

10. 実践チューニング事例３選

サイト規模主施策Before → After
技術ブログ15,000 記事リビジョンクリーン＋RedisTTFB 1.9 s → 0.6 s
ニュースサイト100,000 記事postmeta インデックス追加P95 クエリ 420 ms → 140 ms
EC＋ブログ商品 2,000 + 記事 5,000wp-cron サーバー化 + Redis注文ピーク CPU 80 % → 35 %

11. 自動化｜月次・週次メンテバッチ

11-1 WP-CLI スクリプト例（週次）

bashコピーする編集する#!/bin/bash
wp db optimize               # テーブル最適化
wp transient delete --all    # 期限切れトランジェント削除
wp revisions clean --days=30 # 30日超リビジョン削除

サーバーパネル → Cron 設定 → 毎週日曜 3:00 に登録。

11-2 Slack 通知（失敗検知）

bashコピーする編集するif ! /path/to/script.sh ; then
  curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"DB メンテナンス失敗！"}' \
  https://hooks.slack.com/services/XXX/YYY/ZZZ
fi

12. トラブルシューティング（代表 5 パターン）

症状原因対処
Error establishing DB connectionwp-config のパスワード誤り／DB ダウンパネルでパス確認→ service mysqld restart
Deadlock found同時更新競合トランザクション範囲を短縮／プラグイン更新
超肥大した wp_optionsオートロード 1 MB 超autoload=‘no’ へ変更、削除
Redis “MaxMemory reached”キャッシュに入り切らないパネルで容量拡張 or maxmemory-policy allkeys-lru
Too many connectionsクローラー集中MySQL max_connections 増＋WAF で bot 制限

13. セキュリティと高速化を両立させるポイント

  1. 定期バックアップ は必須（DB のみ毎日＋フル週次）
  2. 二要素認証 で phpMyAdmin を保護
  3. 権限制御：開発者に SELECT のみ権限を分離
  4. WAF：SQL インジェクション遮断はパフォーマンス影響ほぼゼロ
  5. 最新 PHP + MariaDB へ随時アップグレード（脆弱性＆高速化を同時達成）

14. よくある質問

#質問わかりやすい回答
1掃除系プラグインを複数入れてもいい？事故が増えるので 1 つに統一しましょう。重複実行で同じレコードを削除すると不整合が起きます。
2Redis Object Cache と有料 Object Cache Pro の違いは？両者ともキャッシュですが、Pro は統計・圧縮・プリフェッチなど高機能。PV が月 500 万を超えたら検討で十分です。
3インデックスを追加すると壊れませんか？追加は安全です。既存インデックスの削除や変更だけ慎重に。必ずバックアップ後に実行しましょう。
4クラウド型データベースの方が速い？通信遅延があるため、Xserver 内蔵 DB の方が WordPress とは基本的に速くなります。
5バックアップ容量が増えすぎます。工夫は？① 毎日：DBだけ差分　② 週 1：フルバックアップ　③ 古いアーカイブは自動削除、で容量を抑えます。
6スロークエリログはどこで見られる？サーバーパネル →「PHP・DB設定」▶「MySQLスロークエリ」のダウンロードボタンから取得できます。
7PHP を最新版に変えると速くなる？ほぼ毎回 5–10 % は速くなります。テーマ・プラグインの対応状況を確認してから切り替えましょう。
8MariaDB 10 系を 10.x→10.y へ上げるときサイトは止まる？Xserver はローリングアップデート方式で停止しません。ただし念のため深夜に実行し、直後に動作確認を。
9postmeta を削除したらレイアウトが崩れたテーマやプラグインがそこから設定を読んでいる可能性大。削除する前にキー名を調査し、不要なものだけ消しましょう。
10コメントスパムで wp_comments が膨らみますAkismet などで自動ブロックし、「30 日以上前のスパムは自動削除」設定を必ずONに。
11autoload=’yes’ の上限は？合計 1 MB 程度が実務目安。2 MB を超え始めたら整理を検討してください。
12投稿数は何件まで大丈夫？チューニング済みなら 10 万件級でも問題ありません。鍵は postmeta とオプションの管理です。
13wp-cron を止めたら予約投稿が失敗しますサーバークロンで wp-cron.php を呼び出せば解決。記事公開予定の 1 分前には必ず実行されるよう5 分間隔が無難です。
14WP Rocket と Xアクセラレータの相性は？基本両立しますが、双方で HTML キャッシュを有効にすると二重キャッシュになるのでどちらか片方に絞りましょう。
15Elementor を使うと postmeta が急増するテンプレートや履歴をこまめに削除し、不要なリビジョンを制限してください。
16ステージング環境でも最適化すべき？はい。本番と同じ構造でテストしないと、本番公開時にパフォーマンス差が出ます。
17リビジョンを完全に無効化したいdefine('WP_POST_REVISIONS', false); を wp-config に書くと 0 件になります。ただし誤操作復元ができなくなる点に注意。
18DB 接続上限 max_connections は変更できる？共用サーバーでは不可。超える場合はプラグイン数削減か上位プランへ移行しましょう。
19WAF を入れると遅くなる？通常は遅延 5 ms 程度。SQL インジェクション対策のメリットの方が大きいので有効化がおすすめです。
20無料で DB の健康状態を見張るツールは？Query Monitor（WPプラグイン）＋ Xserver リソースグラフの組み合わせが手軽です。
21多言語プラグイン（WPML 等）は遅い？翻訳メタデータが postmeta に増えます。Redis キャッシュと定期掃除で十分カバー可能です。
22サイト内検索プラグインを入れると重い専用インデックスを作るプラグイン（SearchWP など）か Algolia 外部検索を推奨。
23SSL 証明書が切れると DB 速度に影響？直接は無関係。ただしサイト全体が「安全でない」とみなされ離脱増→負荷減ともなります。
24CDN キャッシュを全削除したら遅くなったエッジキャッシュが暖まるまでの一時的現象。心配ならオリジン側でも Xアクセラレータを有効に。
25カスタム投稿ごとに専用テーブルを使える？WordPress コアは未対応。プラグイン「WP Custom Tables」や Headless CMS 移行で実現可能です。

15. 用語集

#用語かみくだき説明
1TTFBブラウザが最初の 1 バイトを受け取るまでの時間。サーバー応答速度を示す。
2MariaDBMySQL 互換のデータベース。Xserver が採用。
3InnoDBWordPress デフォルトのテーブル形式。安全で速い。
4Buffer PoolMariaDB が頻繁に使うデータをメモリにためる場所。
5Query Monitor遅い SQL や PHP エラーを可視化する WP プラグイン。
6スロークエリ実行に長時間かかった SQL。0.5 秒超が目安。
7Redisデータをメモリに保存する高速キャッシュ用 DB。
8Object CacheSQL の結果をオブジェクトとしてキャッシュする仕組み。
9Flushキャッシュを全部空にして最新状態に戻す操作。
10wp-cronWordPress 内蔵のスケジュールタスク機能。
11Cronサーバーが指定時刻にスクリプトを自動実行する仕組み。
12Revision（リビジョン）記事の過去保存履歴。
13wp_posts記事本文や固定ページを格納するテーブル。
14wp_postmeta記事ごとの追加情報（カスタムフィールド）を格納。
15wp_optionsサイト全体の設定やキャッシュを保存。
16autoloadWordPress 起動時に「必ず読み込む」オプション。
17Index（インデックス）データを素早く探すための見出し。
18EXPLAINSQL の実行計画を表示するコマンド。
19P95 / P99全リクエスト中 95 % / 99 % が収まる時間。遅い方を把握する指標。
20IO Waitディスク読み書き待ち時間。高いとサーバーが詰まる。
21OPcachePHP の結果をバイトコードでメモリ保存し再利用。
22LSAPILiteSpeed が作った高速 PHP ハンドラ。
23XアクセラレータXserver 独自のページキャッシュ&高速化機能。
24Brotligzip より高圧縮なテキスト用圧縮方式。
25gzip古くからある圧縮方式。互換性が高い。
26JSON型MariaDB で JSON データを高速格納できる型。
27TTL（Time To Live）キャッシュや DNS レコードの有効期間。
28wp-cliWP をコマンドライン操作できるツール。
29HyperDBWordPress 用のマルチ DB / 読み書き分離プラグイン。
30Primary / Replica書き込み用メイン DB / 読み取り専用コピー。
31Deadlock複数トランザクションが互いを待ち合い停止する状態。
32wp_transient一時キャッシュを wp_options に保存したレコード。
33Cache Hit既にキャッシュにデータがあり即時返せた状態。
34Cache Missキャッシュになく DB へ取りに行った状態。
35LRU（Least Recently Used）キャッシュが満杯時に「最近使っていない物」から捨てる方式。
36wp_commentsコメント本文やステータスを保存するテーブル。
37post_status投稿の状態（publish / draft / trash など）。
38LIKE 検索部分一致検索。インデックスが効きにくく遅い。
39TTL Policy allkeys-lruRedis が容量不足時に古いキーを自動削除する設定。
40MySQLDumpMySQL/MariaDB のバックアップを作るコマンド。
41Service Restartサービスを再起動し設定を読み直す操作。
42EXPLAIN FORMAT=JSON実行計画を JSON 形式で詳細表示する。
43Warm Cacheあらかじめキャッシュをヒットさせて応答を速くしておくこと。
44スローログローテーション大きくなったスロークエリログを分割保存し、ディスク圧迫を防ぐ。
45Headless CMSWP の表示をやめ、API だけ利用するサイト構造。大量記事でも速い。

16. まとめ｜増えても速いサイトを維持する３大原則

  1. 計測 → 掃除 → キャッシュ の順で取り組む
  2. DB に手を入れる前に Xserver 標準機能 を最大活用
  3. 自動化（WP-CLI + cron）で “放置でも速い” 仕組み を作る

これだけで 月100記事ペースでも TTFB 1 秒未満 を現実にできます。

17. まとめ

記事が増えるたびに WordPress が重くなり、読者が離脱していませんか？

速度低下を放置すると SEO も収益も右肩下がり。最悪の場合「接続エラー」でまったく表示されなくなります。

当サイトでは Xserver 専用データベース診断 を無料で実施。TTFB・スロークエリ・オプション肥大をレポート化し、最適化手順までご提案します。

先着 15 サイト限定、6 月 30 日申込分まで。

下のボタンから 60 秒で申し込み、速いブログで読者と売上を伸ばしましょう！

エックスサーバーに申し込む