突然、サイトが「データベース接続確立エラー（Error establishing a database connection）」とだけ表示され、フロントも管理画面も開けない——WordPress運用では誰にでも起こり得る緊急事態です。
原因はひとつではありません。
大切なのは、闇雲に作業せず「再現性のある順番」でチェックし、最短で復旧にたどり着くこと。
本記事は、そのための最短5分の応急フローから原因別の完全対処、さらに再発防止の運用設計までを一気通貫でまとめました。
読了後には「今どこから手を付ければよいか」「どの情報をホストに伝えるべきか」「再発をどう防ぐか」が明確になります。
この記事でわかること
- 最短復旧チェックリストで、まず何を確認すべきか
- 症状の裏で起きているエラーの仕組みと代表メッセージの意味
- 原因別の直し方（設定不一致／接続上限／DB破損／ファイル破損）
- シナリオ別対処（移行直後・更新直後・アクセス急増・ローカル環境）
- ログの見方と問い合わせに必要な情報テンプレ、復旧後の恒久対策
焦らず、順番に進めれば復旧は難しくありません。では、最短5分で確認できる復旧チェックリストから始めましょう。
最短5分で確認：復旧チェックリスト
まずはキャッシュと表示確認（フロントは平常/管理画面はエラー？HTTP 500 か）
最初に「見えているエラーの種類」を切り分けます。
ブラウザのシークレットウィンドウでフロントページと管理画面（/wp-admin/）をそれぞれ開き、フロントか管理画面のどちらかのみエラーか、両方エラーかを確認。
CDNやプラグインのキャッシュが絡むと古い画面が残って判断を誤るため、キャッシュ無効化→再読込が必須です。
サーバー側は、
curl -I https://example.comのHTTPステータスで 200/301/500 を掴みます。
500系ならPHP実行エラーの可能性も高いので、焦点をプラグイン/テーマの直前変更とエラーログに当てます。
ここでエラー文言が「“データベース接続確立エラー”」と明示されているかも確認。
文言が違えば、DB起因以外（PHP致命的エラー等）での停止の可能性が高まります。
wp-config.php の4情報を照合
次にもっとも再現率の高い設定不一致を潰します。
wp-config.php を開き、以下4つをホスティングの実情報と突合してください。
DB_NAME：実在するDB名かDB_USER：該当DBへの権限があるかDB_PASSWORD：直近変更の反映漏れはないかDB_HOST：ホスト固有の値（例：localhost固定やmysql###.xxx.ne.jp指定）
コピペ時に全角・引用符・余計な空白が混ざる事故も定番。
CLIが使えれば
mysql -h <host> -u <user> -pで接続テストし、Unknown database / Access denied / Can’t connect などのメッセージで当たりを付けます。
サーバー障害・過負荷・接続上限の有無（ステータス確認→一時的か恒常か）
共有サーバーでは障害・メンテ・過負荷や接続上限（Too many connections）で一時的に落ちることがあります。
まずはホスティングのステータスページや管理画面のリソース使用量を確認。
アクセス急増が疑われる場合は、ログイン不可でも一時的にプラグインを停止（wp-content/plugins を plugins_off にリネーム）し、重いクエリを出す系（統計・検索・ビルダー）の負荷を逃がします。
CDNやWAFで一時的にキャッシュ強化・静的化するのも有効。
ここまでで復旧の兆しがなければ、次セクションのエラー仕組みの理解に進んで原因を深掘りします。
何が起きている？エラーの仕組みと表示例
WP↔MySQL が切れてページ生成不能になる流れ
WordPressはページ生成のたびにMySQL（MariaDB）へ接続→クエリ実行→HTML出力という流れを取ります。
この最初の接続確立が失敗すると、以降の処理が進まず、WordPressは「データベース接続確立エラー」を出します。
失敗のポイントは大きく4つ：
①認証情報の不一致、
②DBサーバー不達/停止、
③接続上限や過負荷、
④データベース自体の破損。
どこで落ちているかを特定すれば、手当は一気に楽になります。
代表メッセージと意味：「Error establishing a database connection」「Too many connections」など
代表的な文言から原因を逆引きしましょう。
- Error establishing a database connection：総称。まずは**
wp-config.phpの4項目とDBサーバーの稼働**を疑う。 - Access denied for user ‘xxx’@’host’：ユーザー名/パスワード誤り、またはそのDBへの権限不足。
- Unknown database ‘xxx’：DB名の誤り、移行時の作成漏れ、接頭辞不一致の混同。
- Can’t connect to MySQL server on ‘host’：
DB_HOSTが違う、ホスト側の停止、ファイアウォール。 - Too many connections：同時接続が上限に達した状態。アクセス急増や重いプラグインがトリガ。
これらのメッセージはサーバーのエラーログやCLIの接続テストで再現できます。文言を頼りに次の原因別セクションへ進んでください。
どの層に効くか：管理者・制作者・担当者それぞれの視点
サイト運営者はホスト障害・支払い・プラン制限の確認が速く、制作者はwp-config.php照合とプラグイン切り離しが速い。
社内担当者は発生時刻・操作履歴・画面キャプチャを集約し、問い合わせテンプレに落とし込む役回りが向いています。
チームで役割を分けると判断がぶれず、復旧までの時間を短縮できます。
原因1：wp-config.php の認証情報ミスを直す
どこを見直すか（コピペ時の全角/記号、HOST の相違）
wp-config.php の該当箇所を開き、引用符の種類（’ “）、末尾のセミコロン、不可視のスペースなど記号的な崩れも含め慎重にチェックします。
特に DB_HOST は各社固有で、localhost 固定のところもあれば、ホスト名（例：mysql123.sample.ne.jp）やソケットパスを求めるところもあります。
移行直後は旧サーバーの値を持ち越しがちなので最優先で見直してください。
サーバー側情報との突合手順（phpMyAdmin/コントロールパネル）
ホスティングのコントロールパネルで「データベース」「ユーザー」「パスワード」「ホスト名（サーバー名）」を確認し、画面の値をwp-config.phpへ反映します。接続確認は以下の順が確実です。
- CLI接続テスト：
mysql -h <host> -u <user> -p（成功すれば認証は正しい） - DB存在確認：
SHOW DATABASES LIKE 'DB_NAME'; - 権限確認：該当DBに対しユーザーがSELECT/INSERT/UPDATE権限を持つか。足りなければ付与します。
GUIしか使えない場合はphpMyAdminでログインし、DBの存在とテーブル一覧を確認。
テーブル接頭辞（$table_prefix）が wp_ 以外なら、ログインテーブル名などの読み替えも想定します。
DBユーザー権限不足・パスワード変更の未反映を解消
「Access denied…」が出るのにユーザー/パスは合っている場合、DBユーザーがそのDBに紐付いていないのが典型です。
パネル上でユーザー→DBへの割当を行い、必要権限を付与。CLIが使えるなら、管理者でログインして次のように付与します。
GRANT ALL PRIVILEGES ON `DB_NAME`.* TO 'DB_USER'@'%' IDENTIFIED BY 'DB_PASSWORD';
FLUSH PRIVILEGES;
直前にパスワードを変更したものの wp-config.php に未反映、という事故も頻出です。
変更履歴が曖昧なら、新しい強固なパスワードを再発行→wp-config.phpに反映→接続テストが最短ルート。
DB_NAME のスペルや大文字小文字も再点検し、問題が残る場合は次の「サーバー停止/上限」「破損修復」へ進んでください。
原因2：DBサーバー停止・過負荷・接続上限
共有サーバーで起きやすい事象と見分け方（障害情報・アクセス急増時）
同時接続が急増したときや、同一時間帯に重いバッチが走ったとき、MySQLの接続上限（max_connections）に達してエラーが発生します。
特徴は「たまに表示できる」「管理画面は特に重い」「“Too many connections”がログに出る」などの断続的な失敗。
まずはホスティングの障害・メンテナンス情報を確認し、同時にアクセス解析で直前にPVやボットアクセスが跳ねていないかを把握します。
curl -IでHTTP 200/500を掴み、PHP側が落ちているのか、DB接続確立で落ちているのかを切り分けるのが近道です。
可能ならサーバーのプロセス一覧やMySQLのステータスを見て、長時間実行中のクエリやロックの有無を確認。キャッシュ系プラグインやビルダー系プラグインの更新直後は初回キャッシュ生成の集中で負荷が上がるため、時間経過で解消するケースもあります。
一時復旧の打ち手（プラグイン一時停止・アクセス緩和・問い合わせ時の要点）
応急処置の優先度は次の通りです。
- 重い処理の遮断：
wp-content/plugins/をplugins_off/へリネームして全停止（ログイン不可でも実施可）。必要最小限のプラグインだけ戻します。 - テーマの軽量化：一時的にデフォルトテーマへ切り替え（フォルダ名変更またはWP-CLI）。ビルダー系・検索強化系は後回し。
- キャッシュ強化：CDNやWAFを使って静的化。ホーム/代表ページだけでも長めのTTLを当てると効果的。
- 画像最適化やクロール抑制：メディアの遅延読み込み、robots.txtの一時的なクロール頻度制御で負荷分散。
- 問い合わせ：ホストへ連絡する際は発生時刻・該当URL・前後の操作・ログの抜粋・再現頻度を添付。一時的な上限緩和や混雑ノードの移動を打診します。
恒久対策は「復旧後」の章で詳述しますが、オブジェクトキャッシュの導入、検索・統計系の見直し、クエリ数削減が王道です。
接続上限はユーザー側で直接いじれないことが多いため、発生させない設計に寄せるのが現実的です。
原因3：データベース破損の修復
WP_ALLOW_REPAIR での修復・最適化と注意点（必ず定義削除）
クエリ途中の停止やストレージ異常でテーブル破損が起きると、接続自体は通るものの読み書きで落ちることがあります。
修復するためには、まずはバックアップを取得してから、wp-config.php に以下を追記し、
define('WP_ALLOW_REPAIR', true);
ブラウザで /wp-admin/maint/repair.php を開きます（ログイン不要）。
画面の「データベースの修復」または「修復と最適化」を実行し、結果を確認します。
成功して表示が戻ったら、必ず上記の定数を削除してください（公開のままだと第三者が実行できるため危険）。
この修復で効果が薄い場合は、次のphpMyAdmin / WP-CLIでの個別修復に移行します。いずれにせよ、破損の根本原因（容量逼迫、I/O異常、強制終了、不正プラグイン）は復旧後に洗い出しましょう。
phpMyAdmin／WP-CLI（wp db repair）での修復手順
CLIが使えるならWP-CLIでの一括チェックが迅速です。
# 事前バックアップ（推奨）
wp db export backup-before-repair.sql
# チェックと修復
wp db check
wp db repair
特定テーブルだけ壊れているなら、phpMyAdminで該当テーブルを選択→修復（REPAIR）を実行。
SQLで直接行うなら:
CHECK TABLE wp_options;
REPAIR TABLE wp_options;
復旧してもエラーが残る場合、照合順序（collation）や文字コード（utf8mb4）の不一致が影響していることがあります。
新旧サーバーをまたいだ移行直後は、wp_options の siteurl / home や、テーブル接頭辞（$table_prefix）の不一致も確認。破損が広範囲なら直近のバックアップからのリストアが最短です。
その際、差分（投稿・メディア）の救出方針も同時に設計しておくと復旧速度が上がります。
原因4：WordPressコア／ファイル破損
コア再配置の手順（wp-content を残して上書き）
FTPやファイルマネージャでwp-content と wp-config.php を残し、それ以外のコアファイル（wp-admin、wp-includes、ルートのコアファイル）を公式配布物で上書きします。
WP-CLIが使えるなら以下が確実です。
# コンテンツは保持しつつコアを強制再配置
wp core download --skip-content --force
この操作で改変されたコアや欠損ファイルが正常化します。
合わせてファイル権限を見直し（例：ディレクトリ755/ファイル644）、所有者の齟齬や自動アップデート用の書き込み権限不足も解消しておくと再発を防げます。
PHPの拡張モジュール不足（mysqli等）やバージョン不整合（古すぎ・新しすぎ）も同時に点検しておくと安全です。
プラグイン/テーマが触れない場合の“フォルダ改名”による無効化
管理画面に入れないときは、wp-content/plugins を plugins_off にリネームして全プラグイン無効化、wp-content/themes/テーマ名 を一時的にリネームしてデフォルトテーマへフォールバックさせます。
WP-CLIが使えるなら次の通り。
# すべてのプラグインを停止
wp plugin deactivate --all
# デフォルトテーマへ切替（利用可能な最新のデフォルトテーマ名へ）
wp theme activate twentytwentyfour
これで表示が戻る場合、直前に更新したプラグイン/テーマが犯人である可能性が高いので、一つずつ有効化→再現で特定します。
ビルダー系、検索強化系、統計・解析系はクエリやメモリ使用量が増えやすいため、復旧後は設定の見直しや代替手段の検討も行いましょう。
さらに、オートロード項目の肥大化（wp_optionsのautoload='yes'）が重さの根っこになる例もあるため、必要に応じてオブジェクトキャッシュの導入やオートロード最適化を検討してください。
シナリオ別：状況ごとの直し方
移行直後：DB_HOST／URL／接頭辞の不一致を最優先で潰す
サーバー移行直後のエラーは環境固有値の取り違えが大半です。
DB_HOST が旧環境のまま、ソケット指定が必要、ポート番号が違うなどで接続に失敗します。
wp-config.php の4項目（前述）を新環境の実値へ合わせたうえで、URL差し替え漏れを正します。
# 例：新URLへ差し替え（guidは除外）
wp search-replace 'http://old.example.com' 'https://new.example.com' --skip-columns=guid
wp option update home 'https://new.example.com'
wp option update siteurl 'https://new.example.com'
インポート時のテーブル接頭辞（$table_prefix）違いにも注意。
wp_ 以外ならログイン系テーブル名も変わるため、バックアップの中身と照合します。
DBユーザーの権限付与忘れも定番なのでコントロールパネルでユーザー→DBの関連付けを再確認。
PHPバージョンの差（例：旧7.4→新8.2）で非推奨関数が発火し表示が止まる例もあるため、php -v とエラーログを同時に確認します。
ファイル所有者やパーミッション（例：ディレクトリ755/ファイル644）も正し、OPcacheやCDNの古いキャッシュを必ずパージして挙動を見ます。
更新直後：直前差分のロールバックと安全な切り戻し
コア／プラグイン／テーマの更新直後は、互換性不整合やDBスキーマ更新の途中失敗が原因になりがちです。
管理画面に入れない場合でも、WP-CLI で切り戻しできます。
# 直前に更新したプラグインを一括停止
wp plugin deactivate --all
# 既知の安定版へ入れ直し（例）
wp plugin install classic-editor --version=1.6.3 --force
# テーマもデフォルトへ退避
wp theme activate twentytwentyfour
バックアップがあるならDB→ファイルの順で部分復元し、犯人候補を段階的に戻します。
オートロードが過剰化して起動時に重くなる場合は、復旧後に wp_options の肥大を点検し、統計・ビルダー系の設定を見直します。キャッシュ再生成時に負荷が集中するため、深夜帯の更新やページ単位のプリロードを取り入れると安全です。
アクセス急増：接続数緩和と静的化で“落ちない”設計へ
SNS流入やキャンペーンでアクセスが急増すると、DB接続上限に達しやすくなります。応急処置として全プラグイン停止→最低限のみ復帰、ホームやLPはCDNでキャッシュ強化、検索・統計系を止めて静的化を優先します。
# 重いトランジェントを一掃
wp transient delete --all
# DBメンテ（軽量化）
wp db optimize
恒久対策はオブジェクトキャッシュ（Redis/Memcached）の導入、クエリ数削減、画像・フォントの最適化、検索は外部サービス化など。
どうしても動的処理が重い場合は、重要ページだけ静的書き出し（Jamstack的に）してピークをやり過ごす構成も有効です。
サーバー側の一時的な接続上限緩和については、発生条件とログを添えてサーバー管理をしているホストに相談します。
ローカル開発環境：MySQL未起動・ポート違い・拡張不足
MAMP/XAMPP などではMySQL未起動やポート番号の相違（例：8889）が原因のことが多いです。
DB_HOST は 127.0.0.1、ポート指定は localhost:3306 など環境に合わせます。
# 起動確認（macOS例）
lsof -iTCP:3306 -sTCP:LISTEN
# CLI接続テスト
mysql -h 127.0.0.1 -u root -p
PHPのmysqli拡張が無効、メモリ制限が低すぎると接続後に落ちるケースも。
phpinfo() や php -m で拡張を確認し、memory_limit を適正化します。
URLが http://localhost と http://127.0.0.1 で揺れるとクッキー不整合が出るため、home/siteurl を片方に統一しましょう。
ログの見方と“問い合わせテンプレ”
Web／DBログの要点と抜き出し方
障害の直前〜直後5分を中心にログを読むと、原因が絞れます。代表的な場所は下記です。
- Apache：
/var/log/apache2/error.logもしくは/var/log/httpd/error_log - Nginx：
/var/log/nginx/error.log - PHP-FPM：
/var/log/php-fpm/error.log（ディストリによって異なる） - MySQL/MariaDB：
/var/log/mysql/error.logほか
抽出は以下のコマンドなどで十分。
tail -n 300 grep -i 'Too many\|Access denied\|Unknown database'
sudo tail -n 300 /var/log/nginx/error.log | grep -i 'database\|mysql\|too many\|access denied'
sudo journalctl -u php-fpm --since "30 min ago"
発生時刻・メッセージ・直前の操作を紐づけて並べると、ホスト側の調査も速くなります。個人情報や鍵はマスクして共有しましょう。
ホスティング連絡用テンプレ（そのままコピペ可）
- 発生日時：YYYY-MM-DD hh:mm（JST）／継続時間
- 対象URL：
https://example.com/、管理画面/wp-admin/ - 直前の操作：更新／移行／プラグイン有効化／設定変更 など
- 表示・ログ：画面の文言、
error.log抜粋（時刻付き）、MySQLログの該当行 - 試したこと：
wp-config.php照合、プラグイン一時停止、WP_ALLOW_REPAIR実施 ほか - 環境情報：PHP / MySQL バージョン、WP コアバージョン、使用テーマ
- 要望：障害の有無確認、接続上限の現状、必要に応じた一時緩和の可否
併せて次を添付すると親切です：
wp core version
wp plugin list --status=active
php -v && mysql -V
この粒度まで揃っていれば、「サーバー起因かアプリ起因か」の切り分けが一気に進みます。
復旧後にやる恒久対策
バックアップ設計（自動＋手動、復元訓練までセット）
取得より復元が難しいのがバックアップ。
日次の増分＋週次のフルを原則に、世代保持（例：日7／週4／月3）を決め、別リージョン／別クラウドへ退避します。
DBは
wp db exportで自動取得し、復元手順を季節ごとにリハーサル。
作業直前のオンデマンド・スナップショットも習慣化します。
権限と暗号化（SSE-S3/KMS）を整え、復号テストまで確認して初めて“備えた”と言えます。
DB負荷軽減（オブジェクトキャッシュ／オートロード最適化／クエリ削減）
読み込み回数を減らすのが最も効きます。Redis/Memcachedでオブジェクトキャッシュを有効化し、トランジェントの掃除やクエリ数削減を行います。
# オートロード肥大の概況（概算）
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';"
# 大物を特定
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"
# トランジェント一掃
wp transient delete --all
投稿リビジョンは define('WP_POST_REVISIONS', 5); などで上限化、wp db optimize でテーブルを整えます。
検索や関連記事は外部検索エンジンや事前生成を検討し、クエリモニター系ツールでボトルネックを可視化しましょう。
セキュリティ強化と運用点検（攻撃起点の排除・最小権限・監視）
不正アクセスや脆弱プラグイン経由の改変はDB破損や過負荷の元です。
DISALLOW_FILE_EDIT、FORCE_SSL_ADMIN の適用、最小権限のDBユーザー、wp-config.php のパーミッション適正化（例：640）を徹底。
WAF/ログイン試行制限/2FA を整え、Uptime監視＋ログ監視（エラー急増検知）を入れて早期発見できる体制を作ります。
PHP・WP・プラグインは定期更新のカレンダー運用に乗せ、ステージングでの事前検証→本番適用を標準フローにしましょう。これらを続ければ、同じエラーに再び振り回される可能性は大きく下がります。
まとめ
最後にもう一度だけ大枠を振り返ると、緊急時は
「チェックリスト→原因の切り分け→最短の応急措置→恒久対策」
の順で淡々と進めるのが最短距離です。
とくに wp-config.php の4点照合、接続上限の見極めと一時的な静的化、DB破損時の安全な修復とバックアップの復元訓練は、次の障害で“迷わない”ための投資になります。
復旧のたびに気づきを運用手順に反映し、ログ収集と問い合わせテンプレを整備しておけば、同様のトラブルでも数分で復帰できる体制に近づきます。
コメントを残す