MySQL 5.7 から 8 系へ移行するとき、WordPress で実際に問題になりやすいのは「認証方式」「文字コードと照合順序」「sql_mode と予約語」「設定ファイルの廃止項目」の4点です。この記事では、それぞれで何が変わり、どんな症状が出て、どう確認・対処するかを、移行前の準備から切り戻しの用意まで順に説明します。
移行前に知っておきたい前提
まずバージョンの位置づけを整理します。Oracle の案内では MySQL 8.0 は2026年4月にサポート終了（EOL）を迎えており、長期サポート版としては MySQL 8.4 LTS が用意されています（2026年10月現在）。これから移行するなら、移行先は 8.0 ではなく 8.4 系を検討するのが現実的です。本記事の内容は「5.7 から 8 系へ」の変更点が中心で、8.0 と 8.4 の両方に当てはまるものを扱います。8.4 で追加で変わった点はその都度補足します。
WordPress 側は MySQL 8 系に対応しており、公式の推奨要件も MySQL 8.0 以上または MariaDB の比較的新しい版となっています（表記は WordPress.org の要件ページで確認してください）。問題が起きるのは WordPress コアよりも、古い PHP、独自テーブルを持つプラグイン、DB に直接つなぐ外部スクリプト、手を入れてきた my.cnf の側であることがほとんどです。
アップグレード経路にも注意が必要です。5.7 から 8.0 へのインプレース（同じデータディレクトリのまま）アップグレードは公式にサポートされていますが、5.6 以前から 8 系へ一足飛びにはできません。また 8 系から 5.7 へのインプレースの切り戻しはサポートされていないため、戻す手段は「移行前に取った論理バックアップ（ダンプ）から復元する」になります。
手順1：バックアップと事前チェック
作業はステージング環境で先に通し、本番は後から行います。最初にデータベース全体のダンプを取ります。WP-CLI が使えるならサイトのディレクトリで次のように実行します。
# WordPress の DB をファイルへ書き出す（ファイル名は例）
wp db export backup-before-mysql8.sql
# mysqldump を直接使う場合の例（InnoDB 前提でロックを避ける）
mysqldump --single-transaction --default-character-set=utf8mb4 \
-u wpuser -p wordpress_db > backup-before-mysql8.sqlダンプはサーバーの外にも1部コピーしておきます。続いて、移行先で困る要素を事前に洗い出します。MySQL Shell にはアップグレード前のチェック機能（util.checkForServerUpgrade()）があり、予約語と衝突する名前、廃止された設定、古い形式のテーブルなどを一覧にしてくれます。
# MySQL Shell からアップグレード互換性をチェックする例
mysqlsh -- util check-for-server-upgrade root@localhost:3306 --target-version=8.4.0あわせて、現状のテーブルのストレージエンジンも確認します。古くから運用しているサイトでは MyISAM のテーブルが残っていることがあり、移行の機会に InnoDB へそろえておくとクラッシュ耐性やロックの面で有利です。
-- MyISAM のまま残っているテーブルを探す
SELECT table_name, engine
FROM information_schema.tables
WHERE table_schema = 'wordpress_db' AND engine <> 'InnoDB';手順2：認証方式の変更に備える
MySQL 8.0 では新規ユーザーの既定の認証プラグインが mysql_native_password から caching_sha2_password に変わりました。古い PHP（7.3 以前の mysqlnd）はこの方式に対応しておらず、接続時に「The server requested authentication method unknown to the client」のようなエラーになり、WordPress では「データベース接続確立エラー」として表に出ます。
対策の基本は PHP を更新することです。WordPress の推奨は PHP 8 系なので、この機会に PHP も更新対象にしてください。さらに MySQL 8.4 では mysql_native_password が既定で無効化されており、旧方式のユーザーのままだとログインできません。移行後は、ユーザーの認証方式を次のように確認・変更します。
-- ユーザーごとの認証プラグインを確認
SELECT user, host, plugin FROM mysql.user;
-- caching_sha2_password に切り替える例（パスワードは実際のものに置き換える）
ALTER USER 'wpuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'your-strong-password';TCP で接続する構成では、caching_sha2_password は初回接続時に TLS かサーバー公開鍵のやり取りを必要とします。同じサーバー内でソケット接続（DB_HOST が localhost）なら通常は意識せずに済みますが、DB を別サーバーに置いている場合は接続テストを丁寧に行ってください。
手順3：文字コードと照合順序をそろえる
MySQL 8.0 の既定の文字コードは utf8mb4、既定の照合順序は utf8mb4_0900_ai_ci です。WordPress 自体は utf8mb4 を前提にしているので相性はよいのですが、次の2つでつまずきます。
1つ目は、8 系で作ったダンプを 5.7 や MariaDB に戻そうとすると「Unknown collation: 'utf8mb4_0900_ai_ci'」で読み込めないことです。切り戻しやローカル環境への複製を考えるなら、移行前のダンプを別に保管しておくこと、移行先で新しく作るテーブルの照合順序を意識しておくことが大切です。
2つ目は、古いテーブル（utf8mb4_unicode_ci など）と新しく作られたテーブル（utf8mb4_0900_ai_ci）が混在し、プラグインのクエリが両者を結合したときに「Illegal mix of collations」が出ることです。テーブルごとの照合順序は次で確認できます。
SELECT table_name, table_collation
FROM information_schema.tables
WHERE table_schema = 'wordpress_db';wp-config.php の DB_CHARSET は utf8mb4 にしておき、DB_COLLATE は空欄のままでも WordPress が適切に判断します。照合順序を統一したい場合は、バックアップを取ったうえでステージングで ALTER TABLE ... CONVERT TO CHARACTER SET を試し、表示と検索の動作を確認してから本番に反映してください。
手順4：sql_mode・予約語・廃止された設定を確認する
8.0 の既定の sql_mode には ONLY_FULL_GROUP_BY や STRICT_TRANS_TABLES、NO_ZERO_DATE などが含まれます。WordPress コアは自分の接続でこれらの互換性の低いモードを外す処理（wpdb::set_sql_mode()、フィルター incompatible_sql_modes）を持っているため、コアの動作はまず問題になりません。影響を受けるのは、独自に DB 接続を張るプラグインや外部のバッチ、管理ツールからのインポートです。下書きの post_date_gmt に使われる 0000-00-00 00:00:00 のようなゼロ日付が、厳格モードの接続では「Invalid default value」などのエラーの原因になることがあります。
次に予約語です。8.0 ではウィンドウ関数などの追加にともない RANK、GROUPS、ROWS、WINDOW、SYSTEM などが予約語になりました。独自テーブルの列名にこれらを使い、バッククォートで囲まずにクエリを書いているプラグインはエラーになります。また 8.0 からは GROUP BY が暗黙に並べ替えをしなくなったので、並び順を GROUP BY に頼っていたクエリは ORDER BY を明示しないと結果の順番が変わります。
設定ファイルも見直しが必要です。クエリキャッシュは 8.0 で廃止されたため、my.cnf に query_cache_size や query_cache_type が残っていると未知の変数として扱われ、mysqld が起動しません。sql_mode に NO_AUTO_CREATE_USER を書いている場合も同様です。なお mysql_upgrade は 8.0.16 以降は不要になり、サーバーが起動時にシステムテーブルの更新を行います。
手順5：移行後の動作確認
切り替えが終わったら、まずバージョンと設定を確認します。
SELECT VERSION();
SHOW VARIABLES LIKE 'sql_mode';
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';WordPress の管理画面では「ツール」→「サイトヘルス」の情報タブでデータベースのバージョンを確認できます（画面の表記はバージョンにより異なる場合があります）。そのうえで、投稿の作成・更新・検索、コメント、フォーム送信、EC やメンバーシップ系プラグインの主要な操作を一通り試します。
問題の切り分けには、wp-config.php で一時的にデバッグログを有効にするのが近道です。
// 確認作業中だけ有効にし、終わったら false に戻す
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );wp-content/debug.log に「WordPress database error」で始まる行が出ていれば、どのクエリがどのエラーで失敗したかが分かります。あわせて MySQL のエラーログとスロークエリログも見て、オプティマイザの変化で遅くなったクエリがないかを確認します。
よくある症状と対処の早見
- 「データベース接続確立エラー」：PHP が古く caching_sha2_password に対応していない、または 8.4 で旧方式のユーザーが使えなくなっている。PHP の更新とユーザーの認証方式の変更で対処
- mysqld が起動しない：my.cnf のクエリキャッシュ関連や
NO_AUTO_CREATE_USERが残っている。エラーログの「unknown variable」を手がかりに削除 - 特定のプラグインだけ SQL エラー：予約語の列名、GROUP BY、厳格な sql_mode が原因のことが多い。debug.log のクエリを確認し、プラグインの更新や作者への報告で対応
- 照合順序のエラーや並び順の変化：テーブルごとの照合順序を確認し、ステージングで統一
まとめ
- 移行先は、サポート期間を考えると MySQL 8.4 LTS が現実的（2026年10月現在）
- 作業前にダンプを取り、MySQL Shell のアップグレードチェックで問題を洗い出す
- 認証方式の変更には PHP の更新とユーザーの認証方式の見直しで備える
- utf8mb4_0900_ai_ci と既存テーブルの照合順序の混在、ダンプの互換性に注意する
- 予約語・GROUP BY・my.cnf の廃止項目は、コアよりもプラグインや設定側で問題になりやすい
- 切り戻しはダンプからの復元になるため、移行前のバックアップを別の場所に保管しておく