MySQL 8.0のサポートは、2026年4月21日に出た8.0.46を最後に終わりました。これ以降、8.0には不具合やセキュリティの修正が出ません。

業務システムのデータベースとして、MySQL 8.0は今も多くの現場で動いています。社内のサーバーやEC2に自分たちで入れたMySQLは、AWSのRDSのように運用会社から通知が来ることもありません。気づかないまま、修正の出ない版を使い続けているケースは少なくありません。

本記事では、MySQL 8.0のサポート終了で何が変わったのかを確認したうえで、自社のMySQLの版と動いている場所の確かめ方、移行先の選び方、8.4 LTSへ上げるときに止まりやすい変更点と進め方を整理します。

想定読者

本記事は、次のような方を想定しています。

• 社内のサーバーやEC2で、MySQL 8.0を自分たちで動かしている情報システム担当者
• 保守会社から「MySQLのサポートが切れている」と指摘を受け、何をすればよいか整理したい方
• MySQLを8.4に上げるか、RDSやAuroraへ移すかを比べたい方
• 開発会社が作った業務システムのデータベースが何の版か、把握できていない方

---

MySQL 8.0のサポートは2026年4月に終わった

MySQLの公式サイトの終了告知では、2026年4月21日の時点で、MySQL 8.0は「Oracle Sustaining Support」の扱いになったとされています。この扱いになると、新しい修正は出ません。リリースノートにも「2026年4月、8.0.46をもってMySQL 8.0は終了（End of Life）」と書かれています。

終了後も動き続けるが、修正は出ない

サポートが終わっても、MySQL 8.0はそのまま動きます。困るのは、新しい脆弱性が見つかったときです。修正版が出ないため、外から攻撃される入口が開いたままになります。

取引先のセキュリティチェックや監査で「サポート期間内のソフトウェアを使っているか」を問われたときも、説明が必要になります。データベースは、システムの中で最も重要なデータを持つ部品です。ほかの部品より優先して手を打つ理由はそこにあります。

LTSとイノベーションリリースの違い

MySQLは8.0の後、版の出し方を変えました。長く使う前提のLTS（長期サポート）と、新機能を早く出すイノベーションリリースの2本立てです。

• LTS：8.4と9.7。出た後は必要な修正だけが入り、機能の削除は行われない。サポートはOracleのライフタイムサポートの方針に沿って、プレミアサポート5年と延長サポート3年
• イノベーションリリース：9.x系の途中の版。新機能が入る代わりに、動作の変更や機能の削除もある

業務システムのデータベースには、LTSを選ぶのが基本です。8.4 LTSは2024年4月30日に出ており、2026年10月20日には8.4.13が出ています。

RDS for MySQLは期限が別

AWSのRDS for MySQLを使っている場合は、話が変わります。RDSの8.0の標準サポートは2026年7月31日に終わり、8月1日から延長サポートの料金が自動でかかり始めています。RDSの場合の料金と課金の止め方は、別の記事で解説しています。

---

自社のMySQLの版と、動いている場所を確かめる

最初に、どのシステムで、どの版のMySQLが、どこで動いているかを洗い出します。1つの会社の中に、複数のMySQLが散らばっていることはよくあります。

版を確かめる

MySQLに接続できる担当者がいれば、次のSQLで版がわかります。

SELECT VERSION();

サーバーにログインできる場合は、コマンドでも確かめられます。

mysqld --version

「8.0.」で始まる版が出たら、サポートが終わった8.0です。5.7が出た場合は、2023年にサポートが終わっているので、さらに急ぎます。

動いている場所ごとに、誰が対応するかを整理する

同じMySQL 8.0でも、動いている場所によって、対応する人と方法が変わります。

洗い出しでは、MySQLの版と一緒に、そのMySQLを使っているアプリケーションも書き出しておきます。データベースだけを上げても、アプリケーションが新しい版に対応していないと動かないことがあるためです。

OSのパッケージで入れている場合

LinuxのOSの公式パッケージでMySQLを入れている場合は、OSの提供元が独自に修正を続けていることがあります。この場合、修正の有無はOSの提供元の方針で決まります。使っているOSの版と、そのOSでのMySQLの扱いを確かめてください。OSそのもののサポートが終わっていれば、OSの入れ替えとまとめて計画します。

---

移行先の選び方

移行先は、主に次の3つです。

8.0から9.7へは、8.4を経由する

公式のアップグレード手順では、LTSの系列を飛ばして上げることは想定されていません。8.0から9.7へ上げる場合は、まず8.4へ上げ、その後に9.7へ上げる2段階になります。最初から9.7を目指す場合でも、作業の第1段階は8.4への移行です。

RDS・Auroraへ移す場合

EC2や社内のサーバーで動かしていたMySQLをRDSやAuroraへ移すと、OSの更新やバックアップ、障害時の切り替えをAWS側に任せられます。一方で、RDSにも版ごとの期限があり、期限を過ぎると延長サポートの料金がかかる仕組みです。移した後も版の更新は続くので、更新の作業を誰が担うかは、移行前に決めておきます。

---

MySQLの版の確認や、8.4への移行・クラウドへの移行についてお困りでしたら、c3index にお気軽にご相談ください。

---

8.4へ上げるときに止まりやすい変更点

8.0から8.4への移行で、アプリケーションや運用の手順が止まりやすいのは、次の3つです。いずれも公式マニュアルの「8.4の新機能・変更点」に載っています。

古い認証方式が、初期状態では使えない

8.4では、以前からの認証方式「mysql_native_password」が、初期状態では無効になりました。古いアプリケーションや接続ライブラリがこの方式でしか接続できない場合、8.4に上げた直後にログインできなくなります。

一時的に有効にするには、設定ファイルの [mysqld] の欄に次の1行を加えます。

mysql_native_password=ON

ただし、この方式は非推奨です。有効にして動かしながら、アプリケーション側の接続ライブラリを新しい認証方式（caching_sha2_password）に対応させる計画を立てます。

アプリケーションの言語や接続ライブラリも古い場合

10年近く使っている業務システムでは、MySQLに接続するアプリケーション側も古いことがよくあります。PHPやJavaの古い版で動いていて、接続ライブラリだけを新しくしようとすると、言語の版から上げる必要が出てくる場合です。

こうしたシステムでは、データベースだけの問題として扱うと、途中で作業が膨らみます。MySQLの版を調べるときに、アプリケーションの言語・フレームワーク・接続ライブラリの版も一緒に書き出しておくと、どこまで手を入れる必要があるかを最初に見通せます。言語やフレームワークの期限が近いなら、MySQLの更新とまとめて計画したほうが、テストの回数を減らせます。

レプリケーションの古いコマンドが削除された

「CHANGE MASTER TO」「START SLAVE」「SHOW SLAVE STATUS」など、MASTER・SLAVEという語を使う古いコマンドが、8.4で削除されました。代わりに「CHANGE REPLICATION SOURCE TO」「START REPLICA」「SHOW REPLICA STATUS」などを使います。

アプリケーションよりも、運用の手順書や監視の仕組み、バックアップのスクリプトにこれらのコマンドが残っていることが多くあります。8.4へ上げる前に、運用で使っているスクリプトを検索して洗い出します。

初期設定値が変わった

InnoDB（MySQLの標準の保存の仕組み）の初期設定値が、いくつか変わりました。たとえば次のようなものです。

• innodb_io_capacity：200から10000へ
• innodb_adaptive_hash_index：有効から無効へ
• innodb_change_buffering：allからnoneへ
• innodb_log_buffer_size：16MiBから64MiBへ

設定ファイルで値を明示していない項目は、8.4に上げると新しい初期値で動きます。多くの場合は性能が良くなる方向の変更ですが、本番と同じ量のデータで処理時間を測ってから切り替えるのが確実です。

---

8.4への移行の進め方

移行は、次の順に進めます。

1. 棚卸し：MySQLの版・動いている場所・使っているアプリケーション・運用のスクリプトを一覧にする
2. 事前チェック：MySQL Shellのアップグレードチェッカー（util.checkForServerUpgrade）で、8.4へ上げるときに問題になる設定や定義を洗い出す
3. 検証環境での確認：本番のデータを複製した検証環境を8.4に上げ、アプリケーションの主な画面と夜間の処理、バックアップと復元を確かめる
4. 切り替えの計画：止められる時間帯、切り戻しの方法、関係者への連絡を決める
5. 本番の切り替えと監視：切り替え後しばらくは、遅くなった処理やエラーがないかを重点的に見る

止められる時間がほとんどないシステムでは、8.4の新しいサーバーを別に用意し、レプリケーションでデータを同期させてから切り替える方法もあります。

更新が終わるまでの守り方

移行には時間がかかります。その間は、データベースに外から届く経路を絞っておきます。MySQLのポートをインターネットに公開していないか、アプリケーションのサーバー以外から接続できる設定になっていないかを、まず確かめてください。

---

よくある質問

Q. MySQL 8.0は、サポートが終わると動かなくなりますか？

A. 動きます。止まるのは修正の提供で、データベースそのものは動き続けます。ただし、新しい脆弱性が見つかっても修正は出ません。外からの接続経路を絞るなどの守りを重ねたうえで、移行の計画を立ててください。

Q. 8.0から9.7へ直接上げられますか？

A. 上げられません。公式のアップグレード手順では、LTSの系列を飛ばすことは想定されておらず、8.0から8.4へ上げた後に9.7へ上げる2段階になります。

Q. 8.4へ上げると、アプリケーションの改修は必要ですか？

A. システムによります。古い認証方式でしか接続できない接続ライブラリを使っている場合や、削除されたレプリケーションのコマンドを運用で使っている場合は、修正が必要です。アップグレードチェッカーと検証環境での確認で、必要な修正を事前に洗い出せます。

Q. 社内に詳しい担当者がいません。版の確認から相談できますか？

A. できます。サーバーやデータベースを見せていただければ、MySQLの版と動いている場所、使っているアプリケーションを調べ、8.4へ上げるか、RDSやAuroraへ移すかを比べたうえでご提案します。

---

まとめ

本記事のポイントをまとめます。

• MySQL 8.0は、2026年4月21日の8.0.46を最後にサポートが終わった。動き続けるが、修正は出ない
• 移行先は8.4 LTSか9.7 LTS。9.7へは8.4を経由する。RDS for MySQLは期限と料金の仕組みが別
• まず、MySQLの版・動いている場所・使っているアプリケーションを洗い出し、誰が対応するかを決める
• 8.4では、古い認証方式が初期状態で無効、レプリケーションの古いコマンドが削除、InnoDBの初期設定値が変更。上げる前にチェッカーと検証環境で確かめる
• 移行が終わるまでは、データベースへの接続経路を絞って守る

データベースの更新は、アプリケーションやサーバーの更新と重なりやすい作業です。ほかの期限と合わせて、一度で済む計画を立ててください。

---

c3index に相談する

c3index は、AWSの導入・運用と、業務システムの受託開発・保守を行っているシステム会社です。MySQLの版の確認、8.4への移行、RDSやAuroraへの移行、移行後の運用まで、どの段階でもお気軽にご相談ください。