結論から書くと、MySQL を 5.7 や 8.0 から上げると、PHP のコードがそのままでも、接続できない、SQL がエラーになる、ダンプ（データベースを書き出したファイル）を戻せないといった問題が起きることがあります。原因は主に認証方式、SQL モード、予約語、文字セットと照合順序で、事前に調べられます。検証環境でチェックツールにかけ、画面と定期処理を動かして確かめてから本番を上げます。
この記事では、PHP 自体のバージョンアップ（「サポート切れ PHP を放置するリスクと、対応の優先順位」）、レンタルサーバーでの PHP の切り替え、バックアップの取り方は扱いません。
2026年11月時点のサポート状況と移行先
Oracle の Lifetime Support Policy（2026年10月2日付）では、MySQL のサポート期限は次のとおりです。
| バージョン | 通常サポートの終了 | 延長サポートの終了 |
|---|---|---|
| 5.7 | 2020年10月 | 2023年10月 |
| 8.0 | 2025年4月 | 2026年4月 |
| 8.4 | 2029年4月 | 2032年4月 |
| 9.7 | 2031年4月 | 2034年4月 |
移行先は 8.4 か 9.7 ですが、公式のアップグレードの経路では LTS（長期サポート版）の系列を飛ばせないため、5.7 から 8.4 へは 8.0 を、9.7 へはさらに 8.4 を経由します。レンタルサーバーなら、提供される版と切り替えの予定を契約しているサーバーのマニュアルで確認します。
MariaDB の保守期間は MySQL と別で、Community 版の保守は 10.6 が2026年7月6日に終わり、10.11 は2028年2月16日、11.4 は2029年5月29日までです。版を上げたら mariadb-upgrade でテーブルを確認・更新します。以下は主に MySQL の説明です。
接続できなくなる: 認証方式の変更
MySQL 8.0 では既定の認証方式が mysql_native_password から caching_sha2_password に変わり、上げる前からあるアカウントは元の方式のままです（Changes in MySQL 8.0）。
PHP のマニュアルによると、この方式への完全対応は PHP 7.4.4 からで、7.1.16 より前などの古い PHP は、サーバーの既定がこの方式だと、使っていないアカウントでも「The server requested authentication method unknown to the client」で接続できません。
8.4 では mysql_native_password が既定で無効になり、8.0 で既定の方式を戻すのに使われた default_authentication_plugin も削除されたので、設定ファイルにあれば外します。
8.4 以降へ上げる前に、PHP をサポート中の 8.x にし、アカウントを次のように切り替えます。
ALTER USER 'ユーザー名'@'ホスト名' IDENTIFIED WITH caching_sha2_password BY 'パスワード';BY を省くとパスワードが空になり、期限切れになります。アプリの接続設定（.env など）と同じパスワードにします。この方式は TLS や Unix ソケットなどの安全な接続か、RSA 鍵でのパスワードの受け渡しが要るため、検証環境で PHP から接続できるか確かめてから本番で行います。
SQL がエラーになる: SQL モードと予約語
SQL モードは、SQL をどこまで厳しく扱うかを決める設定です。8.0 の既定値には、GROUP BY に無く、集計（SUM や COUNT など）もしていない列を SELECT に並べる SQL を拒否する ONLY_FULL_GROUP_BY などが入っています。古いサーバーで緩めていたなら、新しいサーバーの既定のままでは通っていた SQL がエラーになります。
「Changes in MySQL 8.0」には、次の変更もあります。
NO_AUTO_CREATE_USERの削除。 設定ファイルに残っていると 8.0 が起動しません。5.7.24 より前の mysqldump のダンプも、ストアドプログラム（データベースに保存した処理）の定義に残っていると読み込めません。- GROUP BY の ASC・DESC（昇順・降順）の削除。 8.0.13 から
GROUP BY 列 DESCのような書き方は使えず、ストアドプログラムなどに残るとアップグレードが失敗し得ます。並び順に頼る SQL は順番が変わり得るので、ORDER BY を書きます。
予約語（SQL で特別な意味を持つ語）も増えました。公式の一覧で (R) が付いた RANK や GROUPS などで、列名 rank を囲まずに書いた SQL は構文エラー（ERROR 1064）になります。`rank` のようにバッククォート記号で囲んで直します。
照合順序のエラー: 文字セットの既定値
8.0 では既定の文字セットが latin1 から utf8mb4 に、照合順序（文字の比べ方の規則）が latin1_swedish_ci から utf8mb4_0900_ai_ci に変わりました（「Changes in MySQL 8.0」）。対象は、文字セットを指定せずに作るデータベースやテーブルです。MariaDB も 11.8 の変更点のとおり、11.6 で既定の文字セットが utf8mb4 に、11.5 で既定の Unicode 照合順序が uca1400_ai_ci に変わりました。
また、utf8mb4_0900_ai_ci は 8.0 で加わった照合順序なので、この名前が入った新しい版のダンプは、5.7 のままの開発環境などに読み込めません。
上げる前の確認手順
-
今の設定を記録する。 MySQL と PHP の版、SQL モード、既定の照合順序、アプリのアカウントの認証方式を、次の SQL などで確かめて残します。
SELECT VERSION(), @@GLOBAL.sql_mode, @@GLOBAL.collation_server; SHOW CREATE USER CURRENT_USER(); -
アップグレードチェッカーを実行する。 公式の管理ツール MySQL Shell の util.checkForServerUpgrade() で、予約語と重なる名前、削除された SQL モード、古い認証方式などを調べます。
-
検証環境の接続設定を本番と揃える。 文字セットは、PDO なら DSN（接続文字列）の charset、Laravel なら config/database.php の
charset・collationで見ます。SQL モードは Laravel がstrict（またはmodes）の値で接続ごとに設定するので、この値も見ます。 -
アプリの SQL を検証環境で通す。 チェッカーは PHP のコードの SQL を調べません。移行先と同じ版の検証環境に本番のコピーを入れ、画面、定期処理、帳票まで動かしてエラーログを見ます。レンタルサーバーで試せなければ、手元に作ります。
-
戻す手順を決めてから本番を上げる。 8.0 から 5.7 へのダウングレードはサポートされないため、上げる前のバックアップから戻す手順と、確認する画面の一覧を先に用意します。
h-system でできること
h-system では、他社や前任者が作った PHP・Laravel のシステムの保守・引継ぎ・バージョンアップを、開発者本人が直接お引き受けしています。MySQL を使ったシステムで、サーバーの移転や OS・PHP の更新後に不具合が出た場合も、ソースコード、データベース、サーバー環境の確認からご相談いただけます。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。