WordPressは記事、ユーザー、設定、コメントなどをMySQLまたはMariaDBのデータベースへ保存します。一般的な運用では「WordPress一つにデータベース一つ」が分かりやすく、障害調査や移転もしやすくなります。技術的には接頭辞を変えて一つのデータベースを共有できますが、初心者が数の節約だけを目的に選ぶと、誤操作や容量管理が難しくなるため注意が必要です。
データベースに保存されるもの
WordPressの投稿本文、固定ページ、カテゴリー、タグ、ユーザー情報、各種設定はデータベースのテーブルへ保存されます。画像そのものは通常wp-content/uploads内のファイルですが、画像のタイトルやURLなどの情報はデータベースにあります。したがってファイルだけ、またはデータベースだけを移しても完全なサイトにはなりません。
テーマの見た目に関する設定やプラグインの設定もデータベースへ入ることがあります。バックアップや移転では、WordPressファイルとデータベースを同じ時点で揃える必要があります。どのデータがどこにあるかを理解すると、容量表示や復元範囲を誤解しにくくなります。
基本は一サイト一データベース
一つのWordPressへ一つの専用データベースを割り当てれば、管理画面でサイトとの対応を追いやすくなります。障害時に対象を切り分けやすく、バックアップ、復元、削除、移転の範囲も明確です。データベース名にドメインの一部や用途を含める場合は、契約先の命名規則と文字数制限に従います。
本番サイトとは別にステージングや検証サイトを作るなら、その環境にも一つ必要と見積もります。自動ステージング機能が内部でどのようにデータベースを作るかはサービスごとに違います。契約可能数だけでなく、同時に使える数、容量上限、ユーザー権限も確認してください。
一つを複数サイトで共有する仕組み
WordPressはテーブル接頭辞を変えることで、同じデータベース内に複数サイトのテーブルを置けます。しかしphpMyAdminでは多数の似た名前が並び、誤って別サイトのテーブルを削除する危険が増えます。一つのデータベース障害や認証情報変更が複数サイトへ影響する点も理解が必要です。
共有はデータベース数が厳しく制限された環境で使われることがありますが、初心者にとって管理上の利点は大きくありません。容量を節約できるとは限らず、テーブルが同じ場所へ集まるだけです。新規契約なら、必要サイト数を個別データベースで運用できるプランを選ぶ方が安全です。
WordPressマルチサイトとの違い
WordPressマルチサイトは、一つのWordPressインストールで複数サイトをネットワーク管理する機能です。単に複数の独立WordPressが同じデータベースを共有する方法とは仕組みと管理が違います。テーマやプラグインの管理、ユーザー権限、バックアップ、移転に専門知識が必要です。
店舗ごとのサイトや学校ブログなど明確な一括管理要件がある場合に検討しますが、個人がブログを二つ作るだけなら、独立したWordPressとして分ける方が簡単です。後から通常サイトをマルチサイトへ変える場合も影響があるため、数の節約だけで選ばないでください。
契約前に見るデータベース条件
比較表で「無制限」と書かれていても、1データベース当たりの推奨容量、サーバー全体の目安、同時接続、バックアップ範囲に条件がある場合があります。公式の機能一覧と利用規約、マニュアルを確認し、サイト数だけで割り算しないことが大切です。
自動バックアップにデータベースが含まれるか、何日保持されるか、復元を自分で実行できるかも確認します。phpMyAdminの提供、外部接続の可否、データベースユーザー数、MariaDBやMySQLのバージョンも、移転や開発を予定する場合は重要です。
- 作成可能なデータベース数
- 1個当たりと契約全体の容量目安
- 自動バックアップの対象と保持日数
- 復元方法と費用
- 管理ツールと対応バージョン
現在のデータベースを確認する
wp-config.phpにはWordPressが接続するデータベース名、ユーザー名、ホスト、テーブル接頭辞が設定されています。公開中サイトでは値を書き換えず、確認だけにします。サーバーパネルのデータベース一覧と照合し、どのサイトがどれを使うか台帳へ記録してください。
使っていないように見えるデータベースも、検証環境や過去サイトが参照している場合があります。削除前に設定ファイル、最終更新、バックアップ、関係者へ確認します。データベース削除は取り消せないことがあるため、数を空ける目的で即削除してはいけません。
サイトを増やすときの設計
公開サイト数に加え、ステージング、移転テスト、期間限定サイトの分を見積もります。事業サイトと個人検証を同じ契約へ置くと、一つの障害や契約停止の影響が広がります。重要度、担当者、請求、アクセス権が違うサイトは契約やサーバーを分ける判断も必要です。
サイトごとにデータベース名、管理者、用途、作成日、バックアップ先、削除予定日を記録します。使い終わった検証環境は、必要データを保存してから計画的に削除します。台帳があれば上限に近づいたときも、残すものを安全に判断できます。
データベース容量が増えたときの調べ方
記事数が少ないのに容量が増えた場合は、投稿リビジョン、一時データ、アクセスログを保存するプラグイン、削除済みプラグインのテーブルなどを候補にします。phpMyAdminで大きなテーブルを確認できますが、名前だけで削除せず、どの機能が使っているかを調べます。最適化を実行する前にもバックアップと復元手順を用意してください。
容量の急増は不具合や攻撃の兆候である場合もあります。増加日とプラグイン変更、アクセス状況、エラーログを照合し、原因を止めてから整理します。数値を下げる目的でSQLを直接実行するのではなく、プラグインの公式削除手順やサーバー会社の案内を優先してください。
普通のブログなら、サイト一つにデータベース一つで覚えればいいんですね。
共有して数を節約するより、間違えにくい分け方を選びます。
はい、管理しやすさは将来の移転や復旧でも役立ちます。
検証環境を作る予定があるなら、その分も含めて数を見積もりましょう。
使っていないように見えても、すぐ削除しないことも分かりました。
サイトとの対応表を作れば、私でも落ち着いて確認できそうです！
とても良い方法です。
名前、用途、バックアップ先まで残しておきましょう。
必要数の見積もり方
現在と今後一年で作る環境を数え、独立データベースで管理できるか確認します。
- 現在の公開WordPress数を数える
- ステージングと移転テストの予定を加える
- 終了予定サイトと保持期間を確認する
- 各サイトを一データベースで割り当てる
- 公式の数・容量・バックアップ条件と照合する
迷わず始めたい人向けの選択肢
広告・PRを含みます。料金と特典は公式ページで最新条件をご確認ください。
記事の数ではなく、WordPressサイトと検証環境の数で考えるんですね。
一サイト一データベースの表を作って、将来分も少し余裕を持たせます！
その見積もりなら迷いにくいです。
削除や共有で無理に数を詰めず、復元しやすい構成を優先してください。
設計完了の基準
必要数が上限内に収まるだけでなく、各データベースの利用サイト、バックアップ、担当者を説明できる状態が完了です。
- 公開サイトと検証環境の数を数えた
- 一サイト一データベースで割り当てた
- 容量とバックアップ条件を確認した
- 既存データベースとの対応表を作った
- 削除候補は参照先と復元方法を確認した
必要なデータベース数と仕様を照合する
公開サイトと検証環境の必要数を数えたら、作成可能数、容量、バックアップ条件を公式ページで確認しましょう。一サイト一データベースを無理なく続けられるかが判断基準です。
広告・PRを含みます。料金・特典・適用条件は公式ページで最新情報をご確認ください。