データベースとは？WordPress運用で知っておきたい基礎

WordPressの管理画面で記事を公開すると、入力した本文はデータベースへ保存されます。しかし、ページの表示に必要な情報がすべてデータベースに入るわけではありません。画像の実体やテーマのプログラムは、サーバー上のファイルとして別に保存されます。

この違いは、サイト移転やバックアップの場面で重要になります。データベースだけを保存しても元のサイトは再現できず、ファイルだけを残しても記事や設定は戻りません。まずはWordPressが二つの保存場所を組み合わせて動く仕組みから押さえておきます。

WordPressはデータベースとファイルを組み合わせて表示する

訪問者がページを開くと、WordPressはデータベースから記事本文や設定を読み出します。次にテーマのテンプレートへ内容を当てはめ、画像やCSSを組み合わせてページを返します。データベースは表形式で情報を管理し、必要な情報を条件に応じて取り出せる仕組みです。

記事の公開やサイト名の変更は、管理画面を通してデータベースへ書き込まれます。担当者がSQLを直接操作しなくても、日常の更新作業はデータベースを使っています。フォームや予約のプラグインも、入力内容や受付状況を独自のテーブルへ保存する場合があります。

データベースの異常は、見た目の崩れだけでなく、記事が表示されない状態や管理画面へ入れない状態につながります。一方で、画像だけが見つからない場合はファイル側の問題も考えられます。障害時は最初から「データベースが壊れた」と決めつけず、どちらの保存場所に問題があるかを分けて確認します。

管理画面の情報は役割別のテーブルに保存される

WordPressのデータベースには、役割ごとに複数のテーブルがあります。標準構成でよく見る名称と役割を知っておくと、バックアップ対象や調査箇所を確認しやすくなります。ただし、先頭の wp_ は設置時に変更できるため、実際の名称はサイトごとに異なります。

一つの記事でも、本文と追加項目は別のテーブルへ分かれることがあります。特定のテーブルだけをコピーすると関連情報が欠ける可能性があるため、仕組みが分からない状態でバックアップ対象を間引くのは危険です。通常はWordPressが使うテーブルを一組として扱います。

画像とテーマはデータベースの外にある

メディアへ画像を登録すると、タイトルや説明などの情報はデータベースへ保存されます。画像ファイルの実体は通常、wp-content/uploads の下に置かれます。データベースを復元してメディア一覧に項目が戻っても、対応するファイルがなければ公開ページに画像は表示されません。

テーマやプラグインも、基本的には wp-content の下にあるファイルとして動きます。テーマ設定の一部はデータベースに保存されるため、どちらか片方だけで完全に復元できるとは限りません。WordPress本体のファイルと wp-config.php も、データベースの外にあります。

この構造を知っていると、バックアップ画面に「データベース」と「ファイル」が別々に表示される理由が分かります。取得日時が大きくずれた二つを組み合わせると、記事には画像があるのにファイルが存在しないといった食い違いが起こります。

wp-config.phpにはデータベースへの接続情報がある

wp-config.php には、データベース名・ユーザー名・パスワード・接続先などが設定されています。このファイル自体がデータベースではなく、WordPressが正しいデータベースへ接続するための情報です。移転後に「データベース接続確立エラー」が出ても、直ちに記事データが消えたとは限りません。

まずは接続先や認証情報が新しいサーバーと一致しているかを確認します。データベースが存在していても、利用者の権限が不足していれば接続できません。反対に、接続設定を不用意に書き換えると別のデータベースを参照する可能性があります。

接続情報にはパスワードが含まれるため、画面のスクリーンショットや作業メモをそのまま社外へ送らないようにします。調査を依頼するときは、秘密情報を伏せたうえでエラー内容と作業時刻を共有します。

日常の管理画面操作もデータベースを書き換える

記事の編集だけでなく、ユーザー追加やメニュー変更もデータベースへの書き込みです。プラグインの有効化によって設定や独自テーブルが追加されることもあります。通販や予約サイトでは、新しい注文が入るたびに事業上重要な情報が増えていきます。

そのため、公開中のデータベースへ直接SQLを実行する作業には慎重さが必要です。文字列の一括置換や不要データの削除は効率的に見えますが、条件を誤ると広い範囲を一度に変更します。実行前に対象を確認し、バックアップと検証環境を用意します。

データ量が増えたからといって、テーブルを手作業で削除するのも避けます。不要になったプラグインのデータか判断できない場合は、提供元の削除手順を確認します。表示速度の問題はデータ量だけで決まらないため、測定せずに最適化を始めないことも大切です。

バックアップと移転では二つを一組にする

復元可能なバックアップには、データベースとWordPressのファイルが必要です。できるだけ近い時刻に取得し、同じバックアップセットとして管理します。保存日だけでなく、対象ドメイン・データベース名・取得方法・保管期限まで記録すると、緊急時に取り違えにくくなります。

サーバー会社の自動バックアップは便利ですが、保存される範囲と世代数はサービスによって異なります。データベースだけが対象なのか、メールやファイルも含むのかを管理画面で確認します。復元が有料であったり、申請に時間がかかったりする場合もあるため、事故の前に手順を試しておきます。

サイト移転でも考え方は同じです。データベースを移したあとにURLを変更する場合、シリアライズされた設定を単純な文字列置換で壊すことがあります。WordPress向けの移転機能やWP-CLIなど、データ構造を扱える方法を選びます。

障害時は接続・データ・ファイルを分けて確認する

サイトが開かないときは、表示されたメッセージと発生時刻を記録します。データベースへ接続できないのか、接続後の処理でエラーになったのか、画像だけが欠けているのかで確認先が変わります。直前に行った更新や移転作業も、原因を絞る重要な情報です。

原因が分からないまま修復や復元を実行すると、調査に必要な状態まで上書きするおそれがあります。まず現在のファイルとデータベースを保全し、接続設定とログを確認します。そのうえで復元が必要と判断したときに、同じ時点のバックアップセットを使います。