タグアーカイブ データベースエラー

  1. ホーム   /  タグ付きの投稿: "データベースエラー"
WordPressでデータベース接続確立エラーが出た時の直し方
2026年8月12日 0

WordPressでデータベース接続確立エラーが出た時の直し方

WordPressで「データベース接続確立エラー」が表示される原因は、wp-config.phpファイル内のデータベース接続情報の誤り、またはデータベースサーバー自体の停止に大別される。まずはこの二点を順に確認すれば、大半のケースは解決する。

エラーメッセージが示す根本的な原因は二つだけ

エラーメッセージが示す根本的な原因は二つだけ

WordPressのインストール時や運用中に「データベース接続確立エラー」というメッセージが表示された場合、WordPressは設定ファイルに書かれた情報でMySQL（またはMariaDB）データベースへ接続できていない。エラー画面にも表示される通り、原因は大きく分けて次の二つだ。

  • 認証情報の不一致（wp-config.phpのデータベース名、ユーザー名、パスワード、ホスト名のいずれかが間違っている）
  • データベースサーバーに接続できない（サーバーが停止している、ネットワーク障害がある、ホスト名が間違っている）

新規インストール直後のエラーでは設定ミスが大半を占め、運用中のサイトで突然発生した場合はサーバー側の一時的なトラブルや、何らかの設定変更が影響している可能性が高い。いずれにせよ、対処のステップは決まっている。

エラー 「データベース接続確立エラー」が画面に表示される
↓
認証情報 確認

wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを再チェック

サーバー 確認

データベースサーバーが稼働しているか、管理画面から確認

■ エラー状態　 ■ 認証情報の確認　 ■ サーバー稼働の確認

最初に確認すべきwp-config.phpの設定

最初に確認すべきwp-config.phpの設定

データベース接続情報を記述するwp-config.phpは、WordPressのルートディレクトリに設置されている。エラーが起きたら、まずこのファイルの中身をファイルマネージャーやFTPで開き、以下の4項目が正しいか確認する。

データベース名（DB_NAME）の確認

DB_NAMEには、使用するデータベースの正確な名前を指定する。多くのレンタルサーバーでは、契約時に自動生成されたデータベース名にアカウント名のプレフィックスが付与される（例: username_wp001）。phpMyAdminやサーバー管理画面のMySQLデータベース一覧に表示される名前と、一字一句たがわず一致させる必要がある。大文字小文字も区別されるため、コピー＆ペーストで転記するのが確実だ。

ユーザー名（DB_USER）とパスワード（DB_PASSWORD）の精査

データベースに接続するためのユーザー名とパスワードも同様に、サーバー側で作成したMySQLユーザーの情報と完全一致させる。パスワードは暗号化されずに平文で記述されるため、見間違いがないか注意する。また、パスワードに特殊文字（’ ” \ $ など）が含まれていると、PHPが正しく解釈できず接続エラーを引き起こすことがある。必要に応じてシングルクォーテーションで囲む、あるいはパスワード自体を英数字のみの強固なものに変更するのも有効な手段だ。

ホスト名（DB_HOST）の指定

DB_HOSTは、WordPressがデータベースサーバーを探しに行く宛先だ。多くの共用サーバーでは localhost で問題ない。しかし、一部のホスティング環境では、データベースサーバーがWebサーバーとは別のマシンで動作しており、専用のホスト名やIPアドレスが割り当てられている。サーバー会社のマニュアルに記載されているホスト名（例: mysql.example.com）を指定する。稀に 127.0.0.1 で接続できるが localhost だとエラーになるケースもあるため、どちらも試す価値がある。

Before（エラー発生時）
define( 'DB_NAME', 'wordpress' ); /* ← 実在しないDB名 */
define( 'DB_PASSWORD', 'mypassword' ); /* ← 誤ったパスワード */
↓
After（修正後）
define( 'DB_NAME', 'user_wp01' ); /* ← 正しいDB名 */
define( 'DB_PASSWORD', 'C0rrect!Pass#' ); /* ← 正しいパスワード */

データベースサーバーが稼働しているか確認する

データベースサーバーが稼働しているか確認する

wp-config.phpの設定が正しいのにエラーが続く場合、問題はデータベースサーバー側にある。まず、利用しているホスティングサービスの管理画面にログインし、MySQLやデータベースのセクションを確認する。

サーバー管理画面からの状況確認

多くのレンタルサーバーでは、cPanelや独自のコントロールパネルからMySQLサーバーの稼働状況や、データベースの一覧、ユーザー管理が行える。対象のデータベースとユーザーが存在し、かつユーザーに適切な権限が付与されているかを確認する。サーバー会社によっては、メンテナンスや障害発生時にステータスページで告知を行っているため、そちらも合わせてチェックする。

phpMyAdminで直接ログインを試みる

サーバーの管理画面からphpMyAdminを起動し、wp-config.phpで指定したのと同じユーザー名とパスワードでログインできるか試す。ログインできればデータベースサーバー自体は稼働しており、認証情報も正しいことになる。ログインに失敗する場合は、パスワードのリセットやユーザーの再作成を検討する。ローカル環境（LocalWPやXAMPPなど）で作業している場合は、MySQLサービスが起動しているか、タスクマネージャーやサービス一覧で確認する。

STEP 1 サーバー管理画面にログインし、MySQLの項目を開く
↓
STEP 2 データベースとユーザーが存在し、リンクされているか確認
↓
STEP 3 phpMyAdminで同じ認証情報を使ってログインできるかテスト
↓
STEP 4 接続できればデータベースは正常、できなければユーザーの再作成を検討

それでも解決しない場合の追加確認項目

それでも解決しない場合の追加確認項目

上記の確認で問題が見つからない場合、より深い部分に原因が潜んでいる。以下の点を順に見ていく。

データベースユーザーの権限を再確認する

MySQLユーザーがデータベースにアクセスするための権限が不足していると、WordPressはテーブルを作成・読み取りできず接続エラーを起こす。phpMyAdminやサーバー管理画面で、該当ユーザーに「ALL PRIVILEGES」が付与されているか確認する。特にデータベースを移行した直後や、手動でユーザーを作成した場合に起こりやすい。

データベースの破損をチェックする

サーバーの突然の停止やディスク障害により、MySQLのテーブルが破損することがある。phpMyAdminで該当データベースを選択し、すべてのテーブルをチェックして「テーブルの修復」を実行する。WordPressが管理画面にアクセスできる状態であれば、wp-config.phpに define('WP_ALLOW_REPAIR', true); を一時的に追記し、http://example.com/wp-admin/maint/repair.php にアクセスして修復する手段もある。修復後は必ずこの行を削除する。

wp-content/db.php ファイルの存在を疑う

一部のキャッシュプラグインやデータベース置き換えプラグインは、/wp-content/db.php というファイルを作成してWordPress標準のデータベース接続処理を上書きする。このファイルが破損していたり、古い設定を保持したままだと、突然データベース接続エラーを引き起こす。FTPでdb.phpを一時的に別名にリネームし、エラーが消えるか確認する。

マルチサイトのwp-config.php設定を見直す

WordPressのマルチサイト（サブディレクトリ型やサブドメイン型）を運用している場合、wp-config.phpにマルチサイト固有の定義定数が正しく記述されている必要がある。DOMAIN_CURRENT_SITE や SUBDOMAIN_INSTALL の値が、実際のURL構成やサーバー設定と矛盾していると、内部的なデータベースクエリが失敗して接続エラーに見えることがある。マルチサイト化した直後や、ドメインを変更した後にエラーが起きた場合は、この設定を疑う。

よくある質問

wp-config.phpの修正後にエラーが変わらないのはなぜか

修正内容を保存しても、サーバーのキャッシュやCDN（コンテンツデリバリネットワーク / 配信網）が古いエラー画面を表示し続けることがある。スーパーリロード（Ctrl+F5やCommand+Shift+R）を試し、それでも変わらなければキャッシュ系プラグインを一時停止するか、サーバー側のキャッシュを管理画面からクリアする。

パスワードやユーザー名は合っているのに接続できない

MySQLユーザーが特定のIPアドレスからの接続に制限されている可能性がある。レンタルサーバーでは「localhost」専用のユーザーが作成されるが、外部から接続するように変更してしまうとWebサーバーからのローカル接続が拒否される。phpMyAdminのユーザーアカウント管理で、ホスト名が「localhost」または「127.0.0.1」になっているか確認する。

レンタルサーバーのサポートに連絡するタイミングはいつか

自身でwp-config.phpの設定確認、phpMyAdminからのログインテスト、管理画面からのデータベース稼働状況確認を行っても解決しない場合は、サーバー側の障害や特殊な構成が原因である可能性が高い。サーバー会社のサポートに「WordPressのデータベース接続確立エラーが出ている」「MySQLに接続できない」と具体的に伝えて調査を依頼する。その際、エラーメッセージのスクリーンショットがあるとスムーズだ。

ローカル環境で同じエラーが出る場合の対処法は

LocalWPやXAMPP、MAMPなどのローカル開発環境では、MySQL（またはMariaDB）のサービスが停止していることが原因の大半を占める。各ツールの管理画面で「Start」ボタンを押してサービスを起動し直すか、OSのシステムトレイから再起動する。ポートの競合（特に3306番）が原因で起動に失敗しているケースもあるため、エラーログを確認する。

データベースの修復をしてもすぐにエラーが再発する

テーブルの修復が一時しのぎで終わる場合、ストレージのディスク容量不足や、ハードウェア的な障害が進行している可能性を疑う。サーバーのディスク使用率を確認し、不要なバックアップやログを整理する。根本的にはホスティングサービスのプラン見直しや、サーバー移転を検討する必要がある。

この記事のポイント

  • データベース接続エラーの原因は「認証情報の不一致」と「サーバー停止」に絞られる
  • wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを最初に確認する
  • phpMyAdminで同じ認証情報を用いて直接ログインし、サーバー稼働をテストする
  • 解決しない場合はユーザー権限・DB破損・db.phpの競合・マルチサイト設定を順に疑う
  • サーバー側の障害が疑われる場合は、ログやディスク容量を確認しサポートに連絡する
佐々木 太陽
, , , , ,
お悩み・トラブル解決
Mail Mintのワンクリック解除リンクでデータベースエラーが出る時の対処
2026年8月10日 0

Mail Mintのワンクリック解除リンクでデータベースエラーが出る時の対処

Mail Mint で配信したメールのワンクリック解除リンクをクリックすると、WordPress のデータベースエラー「Column ‘mint_email_id’ cannot be null」がログに出力される問題は、プラグインのバージョンが古いことが主な原因だ。最新版（バージョン 1.30.0 以降）にアップデートすることで、このエラーは発生しなくなる。

なぜワンクリック解除でデータベースエラーが発生するのか

なぜワンクリック解除でデータベースエラーが発生するのか

Mail Mint のワンクリック解除機能は、メール内のリンクに埋め込まれたハッシュ値から、どの配信（ブロードキャスト）からの解除なのかを特定する。しかし、古いバージョン（1.24.4 以下など）では、ハッシュ値が無効な場合や、該当する配信が存在しない場合に、ブロードキャスト ID を取得する関数が null を返していた。

その結果、購読解除ステータスの更新自体は正常に行われるものの、その後にブロードキャストごとのメタ情報（is_unsubscribe）を記録する際、データベースの mint_email_id カラムに null が INSERT されようとして、WordPress のデータベースエラーが発生していた。

このエラーは、購読解除の処理自体を妨げるものではなく、あくまでログに記録されるだけだが、大量に発生するとサーバーのエラーログが肥大化するなどの影響が出る。

Mail Mint を最新版にアップデートしてエラーを解消する

Mail Mint を最新版にアップデートしてエラーを解消する

開発元はこの問題を認識し、バージョン 1.30.0 で修正をリリースしている。そのため、まずは管理画面からプラグインを最新版に更新しよう。

STEP 1 管理画面の「プラグイン」→「インストール済みプラグイン」を開く
↓
STEP 2 Mail Mint の「更新」リンクが表示されていればクリック
↓
STEP 3 バージョン 1.30.0 以上に更新されていることを確認する

プラグインの自動更新が有効な場合はすでに適用されている可能性もあるが、念のためバージョン表示を確認しておこう。

更新後にエラーが止まったか確認する

更新が完了したら、メールマーケティングのワンクリック解除リンクを実際にテストするか、サーバーのエラーログに同じメッセージが出なくなったことを確認する。WordPress のデバッグモードを有効にしている場合は wp-content/debug.log もチェックする。

Before WordPressデータベースエラー Column ‘mint_email_id’ cannot be null がログに記録される
↓
After エラーは発生せず、静かに購読解除メタが保存される
■ エラー状態　■ 修正後

どうしてもアップデートできない場合の一時的な対処

どうしてもアップデートできない場合の一時的な対処

何らかの理由でプラグインをすぐに更新できない場合、以下のコード修正を適用することでエラーを回避できる。ただし、この修正はプラグインの本体ファイルを直接変更するため、次回のアップデートで上書きされる。あくまで緊急措置として理解しておこう。

修正するファイルは app/Internal/Optin/UnsubscribeConfirmation.php だ。process_one_click_confirmation メソッド内の、$broadcast_email_id を取得した直後の処理を対象にする。

修正前（エラーが発生するコード）

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );

修正後

$broadcast_email_id = EmailModel::get_broadcast_email_by_hash( $hash );
// ... 中略 ...
if ( ! empty( $broadcast_email_id ) ) {
    EmailModel::insert_or_update_email_meta( 'is_unsubscribe', 1, $broadcast_email_id );
}

このガードを追加することで、ハッシュが無効でブロードキャスト ID が null のままでも、データベースエラーが発生しなくなる。購読解除ステータスの更新は問題なく行われるため、最低限の動作は保たれる。

データベースエラーが解消したか確認する方法

データベースエラーが解消したか確認する方法

エラーログを監視して、同じメッセージが出力されなくなったかを確認する。WordPress のデバッグモードが有効な場合は、wp-content/debug.log を直接確認するか、管理画面からデバッグログを表示するプラグインを使うと手軽だ。サーバーのエラーログ（エラーログファイルや php-fpm のログ）にも同様のエントリがないかチェックする。

また、テスト用のメールを送信し、そのワンクリック解除リンクを実際にクリックして、エラーログに新たな記録が発生しないことを確かめるのが確実だ。

よくある質問

アップデートしてもエラーが続く場合は？

キャッシュ系プラグインやサーバーキャッシュが古いバージョンのファイルを保持しているケースがある。全キャッシュをクリアし、ブラウザのキャッシュも削除してから再度確認する。また、他のプラグインとの競合も考えられるため、標準テーマに切り替え、Mail Mint 以外のプラグインを一時的に無効化して切り分けを試みる。

一度発生したエラーログは削除したほうがよい？

特に削除する必要はないが、ログが肥大化してディスク容量を圧迫している場合は、ファイルを空にしたり、ログローテーションを設定したりするのが現実的だ。WordPress の debug.log は管理画面から直接内容を確認できるツールを使うのも手だ。

購読解除のメタ情報が記録されないとどんな問題が起きる？

ブロードキャスト単位での解除率や効果測定の集計が正しく取れなくなる可能性がある。ただし、購読解除そのものは正常に処理されているため、配信停止自体は問題なく行われている。レポートの精度を気にする場合は、エラー解消後に過去分のメタ情報を補完することを検討してもよい。

この記事のポイント

  • Mail Mint のワンクリック解除リンクでデータベースエラーが発生するのはプラグインの古いバグが原因
  • バージョン 1.30.0 以上への更新で根本的に解決する
  • 更新できない場合は null チェックを追加する一時パッチで回避可能
  • エラーは購読解除の処理自体を止めるものではないが、ログの肥大化に注意
  • 修正後はテストメールで解除リンクをクリックし、エラーログを確認する
佐々木 太陽
, , , , , ,
お悩み・トラブル解決
ShopMagicで重複カラムエラーが出る原因とデータベース接頭辞の修正
2026年8月6日 0

ShopMagicで重複カラムエラーが出る原因とデータベース接頭辞の修正

ShopMagic 4.8.6以前のバージョンで、データベースアップグレード中に「カラムが重複しています（Duplicate column name ‘note_context’）」というエラーが発生する場合、原因はプラグイン内部のマイグレーションファイルでテーブル接頭辞が wp_ に固定されていることだ。バージョン4.8.7へのアップデートで修正されるが、すぐにアップデートできない場合は、データベースのオプション値を直接編集する緊急回避策でエラーを止められる。

なぜShopMagicで重複カラムエラーが発生するのか

なぜShopMagicで重複カラムエラーが発生するのか

ShopMagicには、プラグインが更新されるたびにデータベースのテーブル構造を自動調整する「マイグレーション」機能が備わっている。今回の問題は、マイグレーションファイル Version_42.php の17行目付近で発生する。このファイルは、note_context というカラムが既に存在するかどうかを確認するために SHOW COLUMNS クエリを実行するが、その際に対象テーブルを wp_shopmagic_automation_outcome_logs と決め打ちしてしまっている。

サイトのデータベース接頭辞（wp-config.php の $table_prefix）がデフォルトの wp_ であれば問題は出ない。しかし、セキュリティや複数サイト運用の都合で接頭辞を abc123_ などに変更している場合、wp_shopmagic_automation_outcome_logs というテーブルは存在しないため、SHOW COLUMNS が失敗する。その結果、プラグインは「カラムが存在しない」と誤認し、note_context を追加しようとする。しかし実際には正しい接頭辞のテーブルに既に存在するため、ALTER TABLE が「カラムが重複しています」というエラーで失敗する。

さらに深刻なのは、このエラーによってマイグレーションチェーン全体が止まってしまう点だ。Version 42が失敗として記録されないため、後続のVersion 43から48のマイグレーションがいっさい実行されない。これにより、マーケティングリストやトラッキングメール関連のテーブルが不足し、気付かないうちに一部機能が不完全になる可能性がある。また、エラーはページが読み込まれるたびに繰り返し発生し、デバッグログを大量に汚染する。

カスタム接頭辞サイトでのエラー発生フロー
【Before】 SHOW COLUMNS FROM wp_shopmagic_… を実行
↓ テーブルが存在しないため失敗
↓
【エラー】 プラグインが「カラム不在」と誤認し、ALTER TABLEで note_context を追加しようとする
↓ しかしカラムは既に存在する
↓
【After】 修正後は $table_name を使って正しい接頭辞のテーブルを確認するため、エラーは発生しない
■ エラー発生時の流れ　■ 修正後の動作

データベースエラーを解消するアップデート手順

根本的な解決策は、ShopMagicをバージョン4.8.7以降にアップデートすることだ。このバージョンでは、マイグレーションファイル内のハードコードされた wp_ が削除され、動的に正しいテーブル接頭辞を参照するように修正されている。

管理画面から自動アップデートする

WordPress管理画面の「プラグイン」→「インストール済みプラグイン」で、ShopMagicに利用可能なアップデートが表示されていれば、「今すぐ更新」をクリックする。アップデート後、データベースのアップグレードが正常に走り、エラー通知が消えていることを確認する。

手動でアップデートする

自動アップデートが利用できない場合は、公式リポジトリまたは有料版の提供元から最新のZIPファイルをダウンロードし、管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から上書きインストールする。既存の設定やデータが失われることはないが、不安な場合は事前にサイト全体のバックアップを取得しておく。

アップデートできない場合の緊急回避策

アップデートできない場合の緊急回避策

何らかの理由ですぐにプラグインをアップデートできない場合、データベースのオプション値を直接書き換えることでエラーの無限ループを止められる。この方法は、マイグレーションVersion 42が「未完了」として記録されているために毎回実行される状態を、「完了」とマークするものだ。Version 42が実際に行うべきテーブル変更（カラム追加）はエラーを起こしながらも既に成功しているため、安全性は高い。

緊急回避の手順
STEP 1 必ずデータベース全体のバックアップを取る
↓
STEP 2 phpMyAdminなどで wp_options テーブルを開く（接頭辞は環境に合わせる）
↓
STEP 3 option_name が shopmagic_db の行を探し、編集する
↓
STEP 4 option_value を WPDesk\ShopMagic\migrations\Version_42 に変更して保存する
注意: phpMyAdmin上ではバックスラッシュのエスケープ処理が自動で行われるため、入力時は WPDesk\ShopMagic\migrations\Version_42 とシングルバックスラッシュで入力する。保存後に LENGTH(option_value) が38（35ではない）であることを確認すれば、正しく保存されている。

変更を保存して管理画面を再度読み込むと、ShopMagicはVersion 42のマイグレーションが完了したと認識し、続けてVersion 43から48の未実行マイグレーションを順次処理する。これにより、不足していたテーブルが自動的に作成され、エラー通知も消える。なお、マイグレーション44では既存のオプトインメールデータを作成済みのマーケティングリストテーブルにコピーする処理が含まれるため、データ量によってはページの読み込みに時間がかかることがある。

よくある質問

エラーが解消された後、不足していたテーブルは自動的に作られるのか

アップデートまたはオプション値の書き換え後、ページを読み込んだタイミングで自動的に不足テーブルが作成される。Version 43から48のマイグレーションが順次実行され、マーケティングリストテーブルやトラッキングメールテーブルなどが生成される。特別な操作は不要だ。

データベース接頭辞をデフォルトのwp_に変更すれば直るのか

接頭辞の変更はサイト全体に影響を与える大掛かりな作業であり、推奨しない。テーブル名の一括置換やwp-config.phpの編集、シリアライズ化データの再計算などが必要になる。このエラーはプラグイン側の問題であり、ShopMagicをアップデートするだけで解決するため、そちらを優先する。

この問題はShopMagic以外のプラグインでも起きるのか

プラグインが内部でデータベース接頭辞をwp_に決め打ちしている場合、全く同じメカニズムでエラーが発生する。ただし、多くのプラグインはWordPressの$wpdb->prefixを用いて動的に接頭辞を取得するため、一般的な問題ではない。カスタム接頭辞を使用しているサイトで特定のプラグインだけがエラーを起こす場合、同様のハードコードが原因である可能性を疑うとよい。

phpMyAdminから直接オプション値を変更するのが不安だ

WP-CLIが利用できる環境であれば、wp option update shopmagic_db 'WPDesk\ShopMagic\migrations\Version_42' --format=plain というコマンドで安全に同じ変更が行える。phpMyAdminを使う場合でも、該当行の編集後すぐに管理画面を開き、エラー通知が消えたことを確認すれば問題ない。

この記事のポイント

  • エラーの直接原因は、マイグレーションファイル内でテーブル接頭辞が wp_ に固定されていること
  • カスタム接頭辞を使うサイトでは、毎回のページ読み込みでエラーが繰り返される
  • ShopMagicをバージョン4.8.7以降にアップデートすれば根本解決する
  • アップデートできない場合、shopmagic_db オプションを手動で進める緊急回避策がある
  • 回避策を取ったあと、後続のマイグレーションが自動実行され不足テーブルも作成される
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPressで「Duplicate entry」データベースエラーが出た時の原因と直し方
2026年8月6日 0

WordPressで「Duplicate entry」データベースエラーが出た時の原因と直し方

プラグイン更新後に debug.log へ「WordPress database error Duplicate entry」が大量出力される問題は、テーブルに一意キーを追加する際、既存データに空の値や重複が存在するために起きている。このエラーそのものはサイトの表示を直ちに壊すわけではないが、ログファイルが急激に肥大化してサーバーのディスク容量を圧迫するため、早期の対処が必要だ。

なぜこのエラーが発生するのか

なぜこのエラーが発生するのか

プラグインのバージョンアップで、データベースのテーブル構造（スキーマ）が変更されることがある。今回のように wp_blc_links テーブルに url_hash カラムを追加し、さらにそのカラムへ UNIQUE KEY（一意キー制約）を設定しようとした場合、既存のレコードの中に同一のハッシュ値が重複していると「Duplicate entry」エラーが発生する。

とりわけ問題になるのが、ハッシュ値が空文字列（空の値）のまま残っているレコードだ。空文字列どうしも「同じ値」とみなされるため、一意キー制約に違反してエラーとなる。これは Broken Link Checker に限らず、データベースのスキーマ変更をともなうあらゆるプラグインで起こりうる。

エラーメッセージの後半に「for key 'wp_blc_links.url_hash'」と表示されているなら、url_hash 列の重複が原因と特定できる。この情報を手がかりに、次の対処へ進む。

まずはログの肥大化を止める

まずはログの肥大化を止める

このエラーはサイトの表示に影響を与えないケースが多いが、放置すると debug.log が一晩で数百 MB に膨れ上がる。ディスク容量が尽きればサイト全体が停止するため、真っ先にログ出力を食い止める必要がある。

プラグインを前のバージョンに戻す

最も確実なのは、問題が発生しなかった旧バージョンへ差し戻す方法だ。プラグインの公式ページにある「以前のバージョン」セクションからダウンロードし、手動でアップロードして上書きする。WordPress 管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP ファイルを指定すればよい。

プラグインを一時的に無効化する

旧バージョンの入手が難しい場合や、そもそもこのプラグインがサイト運営に必須でなければ、無効化するだけでログ出力は止まる。「プラグイン」→「インストール済みプラグイン」から該当プラグインを無効化するだけだ。無効化しても、これまでに収集されたリンク切れのデータはデータベースに残るため、後で有効化すれば以前の状態から再開できる。

Before（エラー発生中）
プラグイン v2.4.9 有効化された状態
debug.log へ毎秒数百件の重複エラーが記録される
→ 数時間で数百 MB に肥大化
↓
After（対処後）
プラグイン 旧バージョン または無効化
debug.log へのエラー出力が停止
→ ログファイルは正常サイズを維持
■ エラー出力が続く状態　 ■ 対処後（ログ出力停止）

上図は、プラグインのバージョンを戻すか無効化する前後でのログ出力の変化を表している。どちらの方法でも、エラーの無限出力はすぐに止められる。

データベースの重複を手動で修正する

データベースの重複を手動で修正する

プラグインの新バージョンを使い続けたい場合や、修正パッチのリリースを待たずに根本解決したい場合は、データベースを直接操作して重複レコードを削除する方法がある。ただし、操作を誤るとサイト全体に影響が出るため、必ず事前にデータベースのバックアップを取得しておく。

phpMyAdmin から重複行を特定して削除する

レンタルサーバーの管理画面から phpMyAdmin を開き、該当の WordPress データベースを選択する。wp_blc_links テーブル（接頭辞は環境により異なる）を表示し、「SQL」タブで次のクエリを実行すると、url_hash が空のレコードと重複しているレコードを確認できる。

SELECT url_hash, COUNT(*) 
FROM wp_blc_links 
GROUP BY url_hash 
HAVING COUNT(*) > 1;

このクエリで表示される行が、一意キー制約に違反する重複レコードだ。続けて、重複しているレコードのうち不要なものを削除する。url_hash が空文字列のレコードをすべて削除してしまえば、多くのケースでエラーは解消する。

DELETE FROM wp_blc_links WHERE url_hash = '';

削除後、プラグインを最新バージョンにアップデートするか、一度無効化してから再度有効化すれば、テーブルのスキーマ変更が正常に完了する。エラーログへの出力も止まるはずだ。

WP-CLI が使える環境での対処

サーバーに SSH 接続でき、WP-CLI がインストールされているなら、コマンドラインからより安全に操作できる。まずは重複を確認する。

wp db query "SELECT url_hash, COUNT(*) FROM wp_blc_links GROUP BY url_hash HAVING COUNT(*) > 1;"

問題が確認できたら、同様に空ハッシュのレコードを削除する。

wp db query "DELETE FROM wp_blc_links WHERE url_hash = '';"

操作後はプラグインを再有効化し、debug.log からエラーが消えたことを確認する。WP-CLI を使う最大の利点は、誤って操作しても wp db export で事前にバックアップを取りやすく、復旧が容易な点だ。

再発防止と注意点

再発防止と注意点

プラグインのアップデートは自動更新に任せず、可能であればステージング環境で事前にテストする運用が望ましい。とくにデータベースのスキーマ変更をともなうアップデート（変更履歴に「database」「schema」「table」「column」といった単語が見られるもの）は要注意だ。

また、debug.log が常に有効になっている環境では、定期的にログファイルのサイズを確認し、不要になったら削除する習慣をつけておくと、ディスク容量の急激な枯渇を防げる。wp-config.php で WP_DEBUG_LOG を true にしている場合は、開発やトラブル解決時以外は false に戻しておくのも有効な対策だ。

よくある質問

重複レコードを削除してもプラグインの機能に影響はないのか

空のハッシュ値を持つレコードは、もともと正常にリンクチェックが機能していないデータだ。削除しても、プラグインは次回のクロール時に改めてリンクを検査して正しいハッシュ値を再生成するため、実害はない。むしろ重複が解消されることで、後続のアップデートも正常に完了するようになる。

このエラーを放置するとどうなるのか

エラーそのものはサイトのフロントエンド表示に影響しない場合が多いが、debug.log がサーバーのディスク容量を圧迫し、最悪の場合「ディスクフル」でサイト全体がダウンする。また、プラグインのスキーマ変更が完了しないため、以降のアップデートが正常に適用されず、プラグインの一部機能が動作しない状態が続く可能性もある。

Broken Link Checker 以外のプラグインでも同じエラーは起こるのか

起こる。UNIQUE KEY を追加するデータベーススキーマの変更を行うプラグインであれば、同種のエラーが発生しうる。SEO プラグインやセキュリティプラグインの大規模アップデートでも見られるため、エラーメッセージに表示されるテーブル名とカラム名を手がかりにして、同じ手順で対処できる。

phpMyAdmin を使えない場合はどうすればよいか

「WP Data Access」や「Advanced Database Cleaner」のようなデータベース操作ができるプラグインを一時的にインストールして、SQL クエリを実行する方法がある。あるいは、サーバー会社のサポートに依頼して重複レコードの削除を代行してもらうのも一つの手だ。

修正パッチがリリースされるまでのつなぎ対策は

プラグインを旧バージョンに固定し、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」で該当プラグインの自動更新をオフにしておく。公式の変更履歴を定期的にチェックし、修正が含まれたバージョンがリリースされたら手動でアップデートすればよい。

この記事のポイント

  • 「Duplicate entry」エラーは、一意キー制約の追加時に既存データの重複が原因で発生する
  • 緊急対応として、プラグインを旧バージョンに戻すか一時的に無効化する
  • データベースから重複レコードを削除すれば、最新バージョンでも正常動作する
  • 事前のバックアップ取得と、ステージング環境でのテストが再発防止に有効
佐々木 太陽
, , , , ,
お悩み・トラブル解決
WordPressで「Duplicate entry ‘0’ for key ‘PRIMARY’」エラーが発生したときのデータベース修復手順
2026年8月4日 0

WordPressで「Duplicate entry ‘0’ for key ‘PRIMARY’」エラーが発生したときのデータベース修復手順

MailPoetなどのプラグインで「An exception occurred while executing a query: Duplicate entry ‘0’ for key ‘PRIMARY’」というエラーが発生しプラグインを再インストールしても直らない場合、原因はデータベーステーブルの主キーからAUTO_INCREMENT属性が失われていることだ。phpMyAdminでテーブル構造を直接修復すれば解決する。

なぜ再インストールではこのエラーが直らないのか

なぜ再インストールではこのエラーが直らないのか

「Duplicate entry ‘0’ for key ‘PRIMARY’」は、データベースの主キー（PRIMARY KEY）に同じ値「0」を重複して挿入しようとしたときにMySQLが返すエラーだ。通常、主キーにはAUTO_INCREMENTが設定されており、新しい行が追加されるたびに自動で一意の番号（1、2、3…）が振られる。しかしテーブル構造が破損したり、何らかの操作でAUTO_INCREMENT属性が外れたりすると、WordPressやプラグインは新しい行を追加する際に主キーへ「0」や重複した値を挿入しようとして失敗する。

MailPoetを管理画面から削除して再インストールしても、プラグインが使用するカスタムテーブルは削除されずに残ることが多い。テーブルが残っていれば破損した構造もそのままだ。結果として、何度インストールし直しても同じエラーが再発するという状況に陥る。

Before（破損したテーブル）
問題主キーにAUTO_INCREMENTが無い
id INT(11) NOT NULL
↑ AUTO_INCREMENTが欠落
→ 新規行のidが常に0になる
↓
After（修復後のテーブル）
解決AUTO_INCREMENTが有効
id INT(11) NOT NULL AUTO_INCREMENT
↑ 自動で一意の番号が振られる
→ 正常にデータを追加できる
■ エラー状態　■ 修正後

エラーが発生しているテーブルは、エラーメッセージに直接表示されないことも多い。MailPoetの場合、mailpoet_で始まる複数のテーブルのいずれかでこの問題が起きている可能性が高い。具体的にはmailpoet_subscribersやmailpoet_segmentsなど、データを頻繁に追加するテーブルで発生しやすい。

phpMyAdminでデータベーステーブルを修復する手順

phpMyAdminでデータベーステーブルを修復する手順

レンタルサーバーの管理画面からphpMyAdminにアクセスし、以下の手順でテーブル構造を修復する。操作は数分で完了し、特別な技術知識は不要だ。

STEP 1 サーバー管理画面からphpMyAdminを開く
↓
STEP 2 左側メニューからWordPressのデータベースを選択
↓
STEP 3 MailPoetテーブルの「構造」タブを開きAUTO_INCREMENTを確認・再設定
↓
STEP 4 WordPress管理画面でプラグインが正常動作するか確認

対象のデータベースとテーブルを特定する

phpMyAdminを開いたら、左側のデータベース一覧からWordPressサイトが使用しているデータベースをクリックする。データベース名がわからない場合は、WordPressインストールディレクトリのwp-config.phpファイルを開き、DB_NAMEの値を確認する。またはサーバー管理画面の「データベース」セクションでWordPressに関連付けられたデータベース名を探す。

データベースを選択するとテーブルの一覧が表示される。MailPoetのテーブルはmailpoet_という接頭辞で始まる（例：wp_mailpoet_subscribers、wp_mailpoet_newslettersなど）。エラーの原因となっているテーブルを特定するには、まずmailpoet_subscribersなど主要なテーブルの「構造」タブを開き、主キー（通常はidカラム）の「AUTO_INCREMENT」が有効かどうかを確認する。

主キーにAUTO_INCREMENTを再設定する具体的なSQL操作

テーブルの「構造」タブでidカラムの「変更」リンク（鉛筆アイコン）をクリックする。表示された編集画面で「A_I」（AUTO_INCREMENT）チェックボックスにチェックを入れ、「保存」をクリックする。これで主キーにAUTO_INCREMENT属性が再設定される。

もしphpMyAdminのGUI操作でエラーが出る場合は、SQLタブを開いて直接SQL文を実行する。以下のSQLを実行する（テーブル名は実際のものに置き換える）。

ALTER TABLE wp_mailpoet_subscribers MODIFY COLUMN id INT(11) NOT NULL AUTO_INCREMENT;

このSQL文は、wp_mailpoet_subscribersテーブルのidカラムをAUTO_INCREMENT付きで再定義する。同じ問題が他のMailPoetテーブルでも発生している可能性があるため、mailpoet_で始まるすべてのテーブルの構造を確認し、idカラムのAUTO_INCREMENTが外れているものがあれば同様に修正する。

操作後はphpMyAdminの「操作」タブから、そのテーブルのAUTO_INCREMENTの現在値を適切な値に設定しておくとより安全だ。テーブル内の既存データの最大IDより大きい値（例：既存の最大IDが150なら151）をAUTO_INCREMENT欄に入力して「実行」をクリックする。

データベースに直接アクセスできない場合の代替手段

レンタルサーバーによってはphpMyAdminが提供されていなかったり、セキュリティ上の理由でデータベースへの直接アクセスが制限されている場合がある。その場合は以下の方法を試す。

WP-CLIが利用できる環境なら、以下のコマンドでデータベースに直接SQLを実行できる。

wp db query "ALTER TABLE wp_mailpoet_subscribers MODIFY COLUMN id INT(11) NOT NULL AUTO_INCREMENT;"

WP-CLIもphpMyAdminも使えない共有サーバーの場合は、「Advanced Database Cleaner」や「WP-DBManager」のようなWordPressプラグインを使ってSQLクエリを実行する方法もある。ただし多くのレンタルサーバーにはphpMyAdminが標準で用意されているため、まずはサーバー管理画面を確認するのが確実だ。

MailPoetテーブルを完全にリセットして再インストールする方法

MailPoetテーブルを完全にリセットして再インストールする方法

テーブル構造の修復が難しい場合や、破損が広範囲に及んでいる場合は、MailPoetの全テーブルを手動で削除してからプラグインを再インストールする方法もある。この方法では既存の購読者データやニュースレターの設定は失われるため、事前にバックアップがある場合のみ選択する。

全リセットの手順
① phpMyAdminでDROP TABLE を実行
mailpoet_ で始まる全テーブルを削除
② WordPress管理画面からMailPoetを削除
プラグイン一覧で「削除」をクリック
③ MailPoetを新規インストール
プラグイン新規追加から再インストール

テーブルを削除するには、phpMyAdminで各mailpoet_テーブルにチェックを入れ、下部の「処理」ドロップダウンから「削除（DROP）」を選択して実行する。MailPoetのテーブルは数が多いため、一つずつ選択するか、以下のようなSQLを実行して一括削除することもできる。

DROP TABLE IF EXISTS wp_mailpoet_subscribers, wp_mailpoet_segments, wp_mailpoet_newsletters;

すべてのMailPoetテーブル名はphpMyAdminのテーブル一覧で確認できる。DROP TABLEは取り消せない操作のため、実行前に必ずデータベース全体のバックアップ（エクスポート）を取得する。その後WordPress管理画面からMailPoetプラグインを削除し、改めて「プラグイン」→「新規追加」からインストールすれば、正常なテーブル構造でプラグインが初期化される。

他のプラグインでも発生する同様のエラーと共通の対処法

他のプラグインでも発生する同様のエラーと共通の対処法

「Duplicate entry ‘0’ for key ‘PRIMARY’」はMailPoetに限らず、WooCommerce、BuddyPress、LearnDashなど、独自のカスタムテーブルを作成するあらゆるプラグインで発生する可能性がある。根本原因は常に同じで、主キーのAUTO_INCREMENT属性が失われていることだ。

WooCommerceの場合はwp_woocommerce_order_itemsやwp_woocommerce_downloadable_product_permissionsなど、BuddyPressではwp_bp_activityやwp_bp_notificationsで発生しやすい。エラーメッセージが表示されたら、まずメッセージ内で言及されているクエリからテーブル名を特定し、そのテーブルの主キー構造をphpMyAdminで確認する手順は同じだ。

プラグイン別の代表的なエラー対象テーブル
WooCommerce
wp_woocommerce_order_items
BuddyPress
wp_bp_activity
LearnDash
wp_learndash_user_activity

WordPressのメジャーアップデートやサーバーのMySQLバージョンアップグレード後にこのエラーが突然発生した場合は、複数のカスタムテーブルで同様の破損が起きている可能性が高い。その際は一つずつ修復するよりも、データベース全体のバックアップを取った上で、DB管理ツールの「テーブルの修復」機能を使うのが効率的だ。phpMyAdminではデータベースを選択後、全テーブルにチェックを入れて「処理」から「テーブルの修復」を選択すると、破損したテーブルを一括で修復できる。

今後の再発を防ぐための予防策

AUTO_INCREMENT属性が外れる根本原因は、MySQLの不整合やプラグインの不完全なアップデート処理にあることが多い。完全に防ぐことは難しいが、以下の対策でリスクを低減できる。

プラグインのアップデート前にデータベースのバックアップを必ず取得する習慣をつける。多くのレンタルサーバーでは管理画面からワンクリックでバックアップを取得できる。また「UpdraftPlus」などのバックアッププラグインを導入し、自動バックアップをスケジュールしておくと、問題発生時に迅速に復元できる。

プラグインのメジャーアップデート（1.xから2.xなど大幅なバージョンアップ）を適用する際は、可能であればステージング環境で事前テストを行う。これにより本番環境でテーブル破損が発生するリスクを大幅に減らせる。ステージング機能を提供しているレンタルサーバーも増えている。

よくある質問

エラーメッセージにテーブル名が表示されない場合はどうすればいいか

WordPressのデバッグモードを有効にすると、より詳細なエラー情報が表示される。wp-config.phpにdefine('WP_DEBUG', true);とdefine('WP_DEBUG_LOG', true);を追加し、wp-content/debug.logに出力されるエラーログを確認する。ログにはクエリ全体が記録されるため、テーブル名が特定できる。

phpMyAdminでAUTO_INCREMENTのチェックボックスがグレーアウトして変更できない

主キーが正しく設定されていない可能性がある。まず「構造」タブでidカラムが「PRIMARY」と表示されているか確認する。表示されていない場合は、そのテーブルのSQLタブでALTER TABLE テーブル名 ADD PRIMARY KEY (id);を実行してから再度AUTO_INCREMENTの設定を試す。

テーブルを修復したが同じエラーが別のテーブルで発生する

プラグインが使用する全テーブルを確認する必要がある。MailPoetは40以上のテーブルを使用しており、idカラムを持つテーブルすべてで同様の問題が起きている可能性がある。phpMyAdminの検索機能で「id」を含むテーブル構造を横断的に確認するか、前述の全テーブル削除と再インストールを検討する。

データベース操作に不慣れでSQLの実行が不安な場合の安全な方法はあるか

レンタルサーバーのサポートに依頼するのが最も安全だ。「WordPressプラグインのデータベーステーブルでAUTO_INCREMENTが破損しているため修復してほしい」と伝えれば、多くのサーバー会社では技術サポートが対応してくれる。またphpMyAdminの「エクスポート」で事前にSQLバックアップを取得しておけば、操作ミスがあっても復元できる。

この記事のポイント

  • 「Duplicate entry ‘0’ for key ‘PRIMARY’」は主キーのAUTO_INCREMENT属性欠落が原因
  • プラグイン再インストールだけではテーブル構造は修復されない
  • phpMyAdminで対象テーブルのidカラムにAUTO_INCREMENTを再設定すれば解決する
  • MailPoet以外のプラグイン（WooCommerce、BuddyPress等）でも同じ対処法が有効
  • 事前のデータベースバックアップとデバッグモード活用で早期発見と安全な修復が可能
佐々木 太陽
, , , , ,
お悩み・トラブル解決
データベース接続確立エラーの原因と復旧手順
2026年7月11日 0

データベース接続確立エラーの原因と復旧手順

「データベース接続確立エラー」でサイトがダウンした場合、まずはサーバー会社に連絡してデータベースサーバーの稼働状況を確認し、wp-config.php の接続情報を照合するのが最短の復旧手順だ。自分でできる対処は限られているため、慌てずに切り分けを進める。

なぜ「データベース接続確立エラー」が突然発生するのか

なぜ「データベース接続確立エラー」が突然発生するのか

このエラーは WordPress がデータベースに接続できないときに表示される。日本語環境では「データベース接続確立エラー」というメッセージが画面に表示され、サイト全体が表示できなくなる。原因は大きく4つに分けられる。

  • wp-config.php 内のデータベース名・ユーザー名・パスワード・ホスト名のいずれかが誤っている
  • データベースサーバー自体がダウンしている（サーバー障害・メンテナンス）
  • データベースサーバーは稼働しているが、負荷集中で応答不能になっている
  • データベースが破損している（テーブルクラッシュなど）

サイトを長期間触っていなかったのに突然エラーが出た場合は、サーバー側で MySQL や MariaDB のバージョンアップ、パスワード変更、セキュリティ設定の変更が行われた可能性が高い。WordPress 側の設定ファイルは変わらないまま、サーバー側の接続条件だけが変わることで不一致が起きる。

Before（エラー発生中）
ブラウザに「データベース接続確立エラー」が表示される
wp-config.php とデータベースの認証情報が不一致、または DB サーバーが停止
↓
After（復旧後）
サイトが正常表示される
正しい接続情報で WordPress がデータベースにアクセスできる状態
■ エラー状態　■ 復旧後

エラーが出たらまず試す3つの切り分け

エラーが出たらまず試す3つの切り分け
STEP 1 サーバー会社にデータベースサーバーの稼働状況を確認する
↓
STEP 2 wp-config.php の接続情報をサーバー管理画面の値と照合する
↓
STEP 3 phpMyAdmin などでデータベースに直接接続できるか試す

サーバー会社にデータベースサーバーの状態を問い合わせる

最も確実で早いのが、利用しているサーバー会社のサポートに連絡することだ。データベースサーバーがダウンしていれば、自分で何をしても復旧しない。管理画面にログインできなくても、サーバー会社のコントロールパネル（cPanel や独自管理画面）にアクセスできれば、そこからデータベースの状態を確認できる場合もある。

特に共有サーバー（複数ユーザーで1台のサーバーを共有するプラン）では、他のユーザーの影響でデータベースサーバーに負荷がかかり、一時的に応答しなくなることがある。この場合もサーバー会社側で対処が必要になる。

wp-config.php の接続情報を確認する

FTP ソフトやサーバーのファイルマネージャーで WordPress のインストールディレクトリにある wp-config.php を開き、以下の4つの定数を確認する。

define( 'DB_NAME', 'database_name_here' );
define( 'DB_USER', 'username_here' );
define( 'DB_PASSWORD', 'password_here' );
define( 'DB_HOST', 'localhost' );

これらの値がサーバーのデータベース管理画面（phpMyAdmin やサーバー会社のコントロールパネル）で設定した値と完全に一致しているか確認する。サーバー会社がパスワードをリセットした場合や、セキュリティアップデートでホスト名が localhost から mysqlcluster2.example.com のような専用ホスト名に変更されるケースがある。

wp-config.php に一時的な確認コードを入れる

接続情報が正しいかどうかを切り分けるには、wp-config.php に以下のテストコードを追加する方法も有効だ。エラーメッセージの詳細が表示され、単なる認証エラーなのか、サーバー自体に到達できないのかが判別できる。

$link = mysqli_connect( DB_HOST, DB_USER, DB_PASSWORD, DB_NAME );
if ( ! $link ) {
    die( '接続失敗: ' . mysqli_connect_error() );
}
echo '接続成功';
die();

このコードを wp-config.php の /* That's all, stop editing! Happy blogging. */ より上に追記し、サイトにアクセスする。「接続失敗」と表示されれば認証情報かサーバー到達性の問題、「接続成功」と表示されれば WordPress 本体やプラグイン側の別の要因が疑われる。確認が終わったら必ずこのコードを削除する。

phpMyAdmin からデータベースに直接接続する

サーバー会社のコントロールパネルから phpMyAdmin にアクセスし、該当のデータベースを開けるか確認する。開ければ、データベースサーバーは稼働しており、認証情報も正しいことがわかる。開けない場合は、ユーザー名・パスワードが誤っているか、そのユーザーにデータベースへのアクセス権限が付与されていない。

phpMyAdmin 自体が開けない、または読み込みに極端に時間がかかる場合は、データベースサーバーの高負荷やダウンが原因だ。この場合もサーバー会社への連絡が必要になる。

データベースの修復が必要なケース

データベースの修復が必要なケース

wp-config.php の情報が正しく、データベースサーバーも稼働しているのに接続エラーが出る場合、データベースのテーブルが破損している可能性がある。この修復は WordPress の自動修復機能で対応できる。

wp-config.php に以下の1行を追加する。

define( 'WP_ALLOW_REPAIR', true );

その後、ブラウザで https://あなたのサイトのURL/wp-admin/maint/repair.php にアクセスすると、データベース修復画面が表示される。「データベースを修復」または「データベースを修復して最適化」ボタンをクリックすれば修復が実行される。修復完了後は、セキュリティのために必ず追加した行を削除する。

管理画面にログインできない場合の対処

管理画面にログインできない場合の対処

「データベース接続確立エラー」が出ている間は、WordPress の管理画面（/wp-admin）にもアクセスできない。この状態では wp-config.php の確認や修正を WordPress の管理画面から行うことはできず、必ずサーバー側のファイルマネージャーか FTP ソフトを使う必要がある。

FTP の接続情報がわからない場合も、サーバー会社のサポートに連絡すれば、コントロールパネルへのログイン方法やファイルマネージャーの使い方を案内してもらえる。WordPress のログイン情報よりも先に、サーバーの管理画面にアクセスできる状態を確保することが復旧の第一歩だ。

再発を防ぐための日常的な対策

再発を防ぐための日常的な対策

データベース接続エラーは突然発生し、サイト全体が完全に停止するため、予防と早期発見の仕組みを整えておくことが重要だ。

  • サーバー会社のデータベース稼働状況を定期的にチェックする（障害通知メールの設定）
  • データベースの定期バックアップを自動化する（サーバー側のバックアップ機能やプラグインを利用）
  • wp-config.php のバックアップを手元に保管し、接続情報をメモしておく
  • サーバー会社のコントロールパネルと FTP のログイン情報を常に最新に保つ

特にレンタルサーバーの共有プランを利用している場合、サーバー会社がメンテナンスやセキュリティアップデートでデータベースの接続設定を変更することがある。変更の予告メールを見逃さないよう、サーバー会社からのメールは確実に受信できるアドレスに設定しておく。

よくある質問

データベース接続エラーと「重大なエラー」は別のものか

別のエラーだ。「データベース接続確立エラー」はデータベースとの通信そのものができない状態で、サイト全体が表示されない。「このサイトで重大なエラーが発生しました」は WordPress 本体やプラグインの PHP エラーで、管理画面にメールが届く場合もある。後者はデータベースに接続できていることが前提になる。

wp-config.php を修正したのに直らない場合はどうすればよいか

データベースサーバー自体が停止しているか、MySQL のサービスが落ちている可能性が高い。サーバー会社のコントロールパネルで MySQL の状態を確認し、停止していれば再起動を試みる。操作権限がない場合はサーバー会社に依頼する。

データベースのユーザー名やパスワードを忘れた場合はどうするか

サーバーのコントロールパネル（cPanel の「MySQL データベース」など）から確認または再設定できる。WordPress の管理画面からは確認できないため、必ずサーバー側の管理画面を使う。パスワードをリセットした場合は、wp-config.php の DB_PASSWORD も新しい値に更新する必要がある。

データベースの修復でデータが消えることはあるか

WP_ALLOW_REPAIR による修復は、破損したテーブルの構造を修復する機能で、保存されている投稿や設定データを削除することはない。ただし、修復作業の前には必ずデータベースのバックアップを取得しておくことが望ましい。

エラーが断続的に発生する場合の原因は何か

データベースサーバーの負荷が一時的に高まっているか、同時接続数の上限に達している可能性がある。アクセス集中時だけエラーが出る場合は、サーバースペックやプランの見直しを検討する。また、プラグインが非効率なデータベースクエリを大量に発行していないかも確認する。

この記事のポイント

  • データベース接続エラーは wp-config.php の誤りかサーバー側の障害が主因
  • エラー発生時は管理画面にログインできないため、FTP やサーバー管理画面で対応する
  • サーバー会社に連絡してデータベースサーバーの稼働状態を確認するのが最短の復旧手段
  • テーブル破損が疑われる場合は WP_ALLOW_REPAIR で修復を試みる
  • 日常的にバックアップと接続情報の控えを取っておくことで復旧時間を短縮できる
佐々木 太陽
, , , ,
お悩み・トラブル解決
WordPressのキーが長すぎるエラーをMariaDB 11.4で修正する方法
2026年6月13日 0

WordPressのキーが長すぎるエラーをMariaDB 11.4で修正する方法

「指定されたキーが長すぎます。最大キー長は 1000 バイトです」というエラーが WordPress サイトのデータベースで発生した場合、対象となるテーブルの複合インデックス定義で長すぎるカラムのプレフィックス長を制限すれば解決する。これはデータベースの照合順序と文字コードの関係で、インデックスが許容バイト数を超過することが直接の原因だ。

「キーが長すぎる」エラーが発生する根本原因

「キーが長すぎる」エラーが発生する根本原因

このエラーは特定のデータベーステーブルに複合インデックスを作成しようとした際に、インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えたために発生する。MariaDB や MySQL では、InnoDB ストレージエンジンの行フォーマットとサーバー設定によってキー長の上限が決まる。具体的には ROW_FORMAT が COMPACT または REDUNDANT のテーブルでは最大 767 バイトまでしか許容されず、DYNAMIC や COMPRESSED の場合でも実質的に 3072 バイトが上限となる。

今回のようなエラーが顕在化しやすいのは、データベースを MariaDB の最新バージョン（11.4 系など）に移行したタイミングだ。デフォルトの文字コードが utf8mb4 に設定されている環境で、VARCHAR 型のカラムをインデックスに含めると、1 文字が最大 4 バイトとして計算されるため、たとえば VARCHAR(255) のカラムが含まれているだけで、そのカラムだけで 1020 バイトを消費する計算になる。

プラグインが独自に追加した CHANGE_LOG テーブルでは、object_type、object_id、created_at という 3 つのカラムで複合インデックスを作ろうとしている。object_id は外部キーや参照用に VARCHAR で定義されていることが多く、これが長いままだとバイト数制限に引っかかる。解決の本質は、インデックスで実際に使用する範囲を object_id カラムの先頭部分だけに限定することにある。

エラーを特定するための確認手順

エラーを特定するための確認手順

実際のエラーメッセージをログから確認する

データベースエラーの内容を正確に把握するために、まずは WordPress のデバッグログを有効化する。wp-config.php に以下の定数を追加する。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

エラーを再現させたあと、/wp-content/debug.log を確認すると「Specified key was too long; max key length is 1000 bytes」というエラーが記録されているはずだ。このエラーには対象のテーブル名や、キーを作成しようとした SQL 文も含まれている。

テーブルのインデックス定義を直接調べる

データベース管理ツール（phpMyAdmin など）で CHANGE_LOG テーブルの構造を開き、「インデックス」タブを確認する。object_lookup という名前の複合インデックスが存在し、そこに object_id カラムがフルサイズで含まれていれば、これがエラーの原因だと特定できる。

SQL コマンドに慣れているなら、以下のクエリでインデックス情報を取得してもよい。

SHOW INDEX FROM wp_change_log;

文字コードとバイト数の関係を理解する

utf8mb4 は 1 文字を最大 4 バイトで表現するため、VARCHAR(255) として定義されたカラムは、インデックス上で最大 1020 バイトを占める。複合インデックスでは、含まれる全カラムの最大バイト数の合計が制限値となる。VARCHAR(100) なら最大 400 バイト、VARCHAR(50) なら 200 バイトと計算していき、上限（1000 バイトや 767 バイト）を超えていないかを確認する。この計算を怠ると、一見問題ない定義に見えても実行時にエラーとなる。

複合インデックスを修正する具体的な手順

複合インデックスを修正する具体的な手順

修正の基本方針は object_lookup インデックスから既存の定義を削除し、object_id カラムのプレフィックス長を制限した新しいインデックスを作り直すことにある。これによりバイト数制限を回避しながら、インデックスの機能自体は維持できる。

修正前（エラー）
KEY object_lookup (object_type, object_id, created_at)
↑ object_id がフルサイズのためバイト数制限を超過
↓
修正後（正常）
KEY object_lookup (object_type, object_id(100), created_at)
↑ object_id の先頭100文字分だけをインデックス化

このデモは object_id にプレフィックス長を設定する前後のインデックス定義の違いを表している。修正後はバイト数制限に収まるため、エラーが解消される。

phpMyAdmin で安全にインデックスを変更する

データベースの直接操作に不慣れな場合、phpMyAdmin を使うとミスが少ない。該当テーブルを開き、「構造」タブから「インデックス」セクションに移動する。object_lookup インデックスを選択して削除し、新たに「インデックスを作成」から複合インデックスを追加する。

カラムを選択する際、object_type と created_at はそのまま指定し、object_id だけ「サイズ」欄に 100 と入力する。これで object_id(100) としてインデックスが作成される。

SQL コマンドで直接修正する場合

コマンドラインや SQL タブから実行するなら、以下の 2 文を順に実行する。DROP で既存のインデックスを削除し、ADD で新しいインデックスを作成する。

ALTER TABLE wp_change_log DROP INDEX object_lookup;
ALTER TABLE wp_change_log ADD INDEX object_lookup (object_type, object_id(100), created_at);

実行前に必ずデータベースのバックアップを取得すること。誤った ALTER TABLE はテーブル構造を壊す可能性がある。

プラグインのアップデートで上書きされないようにする

このインデックスはプラグインが管理するスキーマファイル（class-change-log-schema.php）で定義されているため、プラグインがアップデートされると修正が上書きされてしまう可能性が高い。恒久的な対策としては、プラグインのアクティベーションフックやスキーマ更新処理にフックし、独自のインデックス定義を適用するコードを子テーマの functions.php かカスタムプラグインに記述する方法が有効だ。

データベースのバージョンや設定に依存する問題のため、サーバー環境を変更しない限りこの修正は必須となる。プラグイン開発者が将来的に修正を加えるまでは、自前のフックで対応しておくと安全だ。

よくある質問

このエラーは MariaDB 11.4 だけで発生するのか

MariaDB 11.4 に限らず、キー長制限が厳格に適用される環境ならば発生する可能性がある。古い MySQL 5.6 以前の設定や、InnoDB の ROW_FORMAT が COMPACT のテーブルでも同様のエラーが起こる。

object_id(100) のようにプレフィックスを制限しても検索性能は落ちないのか

先頭 100 文字までをインデックス化するため、100 文字を超える部分での検索精度は低下する可能性がある。ただ、object_id のような識別子は冒頭部分で十分に一意性が確保されることが多く、実際のクエリ性能に大きな影響は出ない。

エラーが WordPress 本体のテーブルで出た場合はどうすればよいか

WordPress コアのテーブルでこのエラーが発生することは稀だ。通常はプラグインやテーマが独自に追加したカスタムテーブルで起こる。もしコアテーブルで起こった場合は、データベースの文字コードや ROW_FORMAT の設定自体を見直す必要がある。

SQL の直接実行が不安なときの代替手段はあるか

WP-CLI（WordPress のコマンドライン管理ツール）が利用できるなら、「wp db query」コマンドで安全にクエリを実行できる。また、データベースの移行や最適化を支援するプラグイン（WP Migrate など）にも SQL 実行機能が備わっているものがある。

この記事のポイント

  • インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えるとキー長エラーが発生する
  • utf8mb4 環境では VARCHAR 型のカラムが 1 文字最大 4 バイトを消費する点に注意が必要
  • object_id(100) のようにカラムのプレフィックス長を指定してインデックスを再作成することでエラーを回避できる
  • プラグインのアップデートで修正が上書きされるため、恒久的な対処にはフックを用いたコード管理が推奨される
佐々木 太陽
, , , ,
お悩み・トラブル解決

メニュー

会社概要
事業紹介
社名の由来
JVパートナー募集

ウェブ開発 最新ニュース

B to B のご提案

事業譲渡（M&A）
卸売販売
アフィリエイト

その他

関連サイト
特定商取引法に基づく表示
プライバシーポリシー
お問い合わせ

Copyright 株式会社A&Gウェブ - ライバルには、ひみつ。 All rights reserved.