MySQL 5.7と8.0の違いを比較｜性能・機能・認証とEOL後の移行先

MySQL 5.7と8.0の違いは、性能・新機能・認証方式の3点に集約されます。ただし2026年時点では「どちらを使うか」の議論そのものが変わりました。MySQL 5.7は2023年10月にサポートを終え、MySQL 8.0も2026年4月にサポート終了（EOL）を迎えたためです。本記事では両バージョンの違いを比較表で整理したうえで、アップグレードで性能が落ちる原因、そしてEOL後に選ぶべき移行先である8.4 LTSまでを、公式のサポート情報にもとづいて解説します。

まとめ：5.7と8.0の違いと、今選ぶべきバージョン

• 性能：8.0はオプティマイザ刷新・降順/不可視インデックス・ヒストグラムで多くのクエリが高速化。一方でアップグレード直後に遅くなる事例もあり、原因の切り分けが要る。
• 機能：8.0でCTE・Window関数・インスタントDDL・JSON関数が追加され、デフォルト文字コードがutf8mb4に。クエリキャッシュは削除された。
• 認証：8.0で既定認証がcaching_sha2_passwordに変わり、古いクライアントやmysql_native_password前提のアプリで接続エラーが起きる。これが移行時に最も詰まる箇所。
• サポート：5.7は2023年10月31日、8.0は2026年4月にEOL。いずれも通常のセキュリティ修正は終了している。
• 結論：これから新規構築・移行するなら、長期サポート（LTS）版のMySQL 8.4を選ぶのが基本。5.7・8.0からの移行先も8.4 LTSが第一候補になる。

以降で、比較表・性能・機能・認証・サポート期限・移行手順の順に、それぞれの違いを具体的に見ていきます。

MySQL 5.7と8.0の違いを比較表で早わかり

まず全体像を1枚の表で押さえます。年月やサポート状況は2026年7月時点の公式情報にもとづく値です（最新の細かな改定は公式ライフサイクルで確認してください）。

表で最も重要なのは、5.7と8.0がいずれもEOLを迎えている点です。互換性の観点では既定の認証プラグインと文字コードの変更が実務に直結し、機能面ではCTE・Window関数・インスタントDDLが8.0の中心的な追加要素になります。次章から順に掘り下げます。

パフォーマンスの違いと「8.0にすると遅くなる」問題

MySQL 8.0はオプティマイザとインデックス周りが刷新され、多くのワークロードで5.7より高速に動作します。ただし、アップグレードした途端に一部のクエリが遅くなる報告も一定数あり、両面を理解しておく必要があります。

8.0でクエリが速くなる仕組み

8.0の高速化は主に実行計画の質を上げる機能によるものです。列値の分布を統計として持つヒストグラムにより、インデックスが無い列でも件数を見積もった実行計画を立てられます。降順インデックスはORDER BY col DESCを追加ソートなしで処理し、不可視インデックスは実際に削除する前に「無い状態」を安全に検証できます。データ辞書がInnoDBに統合され、旧来の.frmファイルが廃止された点もメタデータ操作の一貫性に寄与します。

アップグレード後に遅くなる主な原因と対策

「速くなるはずが遅くなった」という事例で狙い目になる原因は、おおむね次の3つに絞られます。競合記事では散発的な体験談として語られがちですが、切り分けの軸を持てば原因を特定しやすくなります。

• クエリキャッシュの消失：8.0でクエリキャッシュは削除された。5.7で同一クエリの結果キャッシュに頼っていた場合、同等の効果はアプリ側キャッシュ（Redis等）で補う必要がある。
• utf8mb4化によるインデックス肥大：既定文字コードがutf8mb4（1文字最大4バイト）になり、文字列インデックスのバイト長が増える。長いVARCHARに複合インデックスを張っている表では、キー長やメモリ効率が変わり得る。
• オプティマイザの実行計画変化：統計やコストモデルの刷新で、5.7と異なる実行計画が選ばれることがある。遅くなったクエリはEXPLAINで5.7時代の計画と比較し、必要ならoptimizer_switchやインデックス追加で調整する。

いずれも「8.0が遅い」のではなく、環境依存の設定差が表面化したケースがほとんどです。移行前にステージング環境で主要クエリの実行計画を取得し、差分の大きいものだけを潰す進め方が現実的です。ロック競合が絡む遅延はトランザクションとロックの関係とデッドロックの防止策も合わせて確認すると原因を切り分けやすくなります。

MySQL 8.0で追加・変更された主な機能

8.0の機能変更は、SQL表現力・データ型/文字コード・廃止された仕組みの3方向に分けると整理できます。

SQL表現力の強化（CTE・Window関数・インスタントDDL）

8.0ではWITH句による共通テーブル式（CTE）と再帰CTEが使えるようになり、階層データの取得を1文で書けます。ROW_NUMBER()やRANK()などのWindow関数も追加され、5.7では変数を使った回避策が必要だった順位付け・累計計算が標準構文で書けます。スキーマ変更ではALTER TABLE ... ADD COLUMNなどがメタデータ更新のみで完了するインスタントDDLに対応し、大きな表への列追加でテーブル全体を再構築せずに済みます。

データ型・JSON・文字コードの変更

既定文字コードがlatin1からutf8mb4へ変わり、絵文字や多言語文字をそのまま格納できます。JSON型は5.7で導入済みですが、8.0ではJSON_TABLE()でJSONをリレーショナルな表として展開でき、JSON_MERGE_PATCH()やJSON_OVERLAPS()などの操作関数も拡充されました。一方でYEAR(2)などの旧式の日付・時刻表現は廃止され、移行時にはデータ型の見直しが必要です。

廃止・削除された仕組み

前章で触れたクエリキャッシュの削除に加え、旧来のメタデータ管理（.frmファイル）や一部の古い予約語の扱いが変わりました。5.7で暗黙に依存していた挙動が8.0で通用しなくなる典型例が、GROUP BY句の暗黙のソートです。8.0では結果の並び順が保証されないため、順序が必要ならORDER BYを明示する必要があります。

認証・セキュリティの変更と互換性の最大の罠

アップグレードで最も詰まりやすいのが認証方式の変更です。8.0では既定の認証プラグインがcaching_sha2_passwordになりました。SHA-256ベースで安全性は高い一方、古いドライバやmysql_native_password前提で作られたアプリケーションは、そのままでは接続時に認証エラーになります。

回避策としては、対象ユーザーの認証プラグインを明示するか、クライアント/ドライバを新しい認証に対応したバージョンへ更新します。ただしこのmysql_native_passwordは8.4 LTSでは既定で無効化され、9.0では完全に削除される方向のため、旧認証を延命する対応は移行を先送りするだけになります。中長期ではアプリ側を新認証に対応させるのが正解です。

権限管理も強化され、8.0では複数の権限をまとめて付与できるロールと、SUPER権限の一部を機能別に細分化した動的権限が導入されました。多数のアカウントに同じ権限セットを配る運用では、ロールにより付与漏れや過剰付与を減らせます。

サポート期限とバージョンの選び方（8.4 LTSへ）

ここまでの違いを踏まえても、2026年時点の実務的な結論は「5.7と8.0はどちらもサポートが終わっており、これから選ぶなら8.4 LTS」です。バージョンごとのサポート状況と選び方を整理します。

5.7・8.0・8.4のサポート状況

EOLを過ぎたバージョンには原則としてセキュリティ修正が提供されません。5.7はもちろん、8.0も2026年内にはサポート切れとなるため、稼働中の環境は移行計画の対象になります。

Innovation版とLTS版の違い

MySQLは8.0以降、リリース方針を2系統に分けています。8.1〜8.3のようなInnovation版は新機能をいち早く取り込む短命リリースで、次の版が出ると更新が止まります。対してLTS版（8.4など）は数年単位でバグ修正・セキュリティ修正が続きます。9.0以降の9.x系はInnovation版であり、頻繁な追随が前提です。本番データベースでは安定性を優先し、LTSの8.4を選ぶのが定石です。

今から移行するなら

5.7・8.0いずれからの移行先も、まずは8.4 LTSを基準に検討します。8.4は主要なクラウドマネージドサービスでも提供が進んでおり、Amazon RDS for MySQLやAzure Database for MySQLでも8.4が一般提供されています（提供リージョンや対応状況は各サービスの最新情報を確認してください）。接続の集約やフェイルオーバー時の挙動を安定させたい場合は、RDS Proxyの概要と特徴も移行設計の検討材料になります。9.x系は新機能検証用と割り切り、本番の常用は避けるのが無難です。

5.7・8.0からアップグレードするときの注意点

移行を安全に進めるため、事前に確認すべき互換性のポイントをチェックリストにまとめます。順に潰していくと、本番切り替え時のトラブルを大きく減らせます。

• 認証プラグイン：caching_sha2_passwordに非対応の古いクライアント/ドライバを洗い出し、更新または設定変更する。
• 文字コード：latin1やutf8（utf8mb3）からutf8mb4への移行でインデックスのキー長・照合順序（collation）が変わる。既存テーブルの文字コードと照合順序を確認する。
• 予約語とSQLモード：8.0で追加された予約語（RANKなど）を識別子に使っていないか、厳格なSQLモードで弾かれるクエリが無いか確認する。
• 暗黙のソート依存：GROUP BYの並び順に依存したクエリはORDER BYを明示する。
• 実行計画の検証：主要クエリをEXPLAINで確認し、遅くなったものはインデックスやオプティマイザ設定で調整する。

アプリケーション側でORMを使っている場合は、生成されるSQLや接続ドライバの対応バージョンも確認対象です。PythonであればSQLAlchemyの基本と使い方のように、ORMがどのドライバ経由で接続しているかを把握しておくと、認証方式の変更に伴う不具合を切り分けやすくなります。

よくある質問（FAQ）

MySQL 5.7はまだ使えますか？サポートはいつ終了しましたか？

MySQL 5.7は2023年10月31日にサポート（EOL）を終えています。動作自体はしますが、新たなセキュリティ修正は原則提供されないため、稼働中の環境は8.4 LTSなどへの移行が推奨されます。

MySQL 5.7と8.0はどちらが速いですか？

多くのワークロードでは8.0が高速です。オプティマイザの刷新やヒストグラム、降順・不可視インデックスにより実行計画の質が上がるためで、公式も特定のワークロードで5.7比「最大2倍高速」としています。ただしこれは環境依存で、クエリキャッシュの削除やutf8mb4化の影響で一部クエリが遅くなることもあり、移行時は主要クエリの実行計画を事前に検証すると安全です。

MySQL 8.0からの移行先はどのバージョンが良いですか？最新版は？

本番環境ではLTS版のMySQL 8.4が第一候補です。9.x系はInnovation版で更新サイクルが短く、常用より新機能検証向けです。最新のリリース状況は公式のリリース情報で確認してください。

MySQL 8.0にアップグレードすると遅くなるのはなぜですか？

主な原因はクエリキャッシュの削除、utf8mb4化によるインデックス肥大、オプティマイザの実行計画変化の3つです。「8.0が遅い」というより環境依存の設定差が表面化するケースが多く、遅くなったクエリをEXPLAINで特定して個別に調整します。

MySQL 5.6と5.7の違いは何ですか？

5.6から5.7では、オプティマイザの改善、JSON型の導入、パフォーマンススキーマの拡充などが行われました。ただし5.6も5.7もすでにサポートを終えているため、これらの旧版を使っている場合は5.7を経由するより直接8.4 LTSへ移行するのが現実的です。

関連記事

• トランザクションとロックの関係とデッドロックの防止策
• RDS Proxyとは何か？概要や特徴をわかりやすく解説
• SQLAlchemyとは？Python ORMの基本と使い方を入門から実践まで解説