MySQL 8.4と8.0の違いとは
なぜMySQL 8.4が重要なのか – LTS版導入の背景
MySQL 8.4は、Oracleが2023年から導入した新しいリリースモデルにおける初のLTS（Long Term Support）版です。
MySQLのリリースは現在、次の2種類に分かれています。
・Innovationリリース：最新機能を優先し短期間で更新（サポート期間は短い）
・LTSリリース：安定性・長期サポートを重視（企業利用を前提）
MySQL 8.0と8.4の機能比較
| カテゴリ | MySQL 8.0 | MySQL 8.4 |
| リリース種別 | 旧モデルリリース（8.0.34以降はメンテナンス保守フェーズ） | LTS（長期サポート） |
| EOL | 2026年4月30日 | 2032年頃（予定） |
| 認証プラグイン | mysql_native_password 有効（非推奨） | デフォルト無効 |
| innodb_io_capacity | 200（デフォルト） | 10,000（デフォルト） |
| GTIDフォーマット | UUID:NUMBER | UUID:NUMBER（標準）／UUID:TAG:NUMBER（タグ付き拡張・任意） |
| MTA+SQL_AFTER_GTIDS | 使用可だがMTAが強制シングルスレッド化 | 両立可能（並列動作維持） |
| MASTER/SLAVE構文 | 非推奨（使用可） | 完全削除 |
| Cloneプラグイン | 8.0.36以前：同一パッチバージョンが必要、8.0.37以降：同一マイナーバージョン内で可 | 同一マイナーバージョン内で可（パッチバージョン差異は許容） |
| Windows SASL/LDAP | 非対応（Linuxのみ対応） | 正式対応（8.3.0 Innovationで初導入） |
MySQL 8.0のまま運用するリスク
2026年4月30日以降、MySQL 8.0はEOLを迎え、新規のバグ修正・セキュリティパッチの提供が停止されます。
具体的には以下のリスクが生じます。
・セキュリティリスク：新たに発見された脆弱性に対してパッチが提供されなくなり、システムが攻撃にさらされる可能性が高まります。
・コンプライアンスリスク：金融・医療・官公庁系のシステムでは、EOLのソフトウェアを本番稼働させること自体が内部監査・外部審査の指摘対象になり得ます。
・運用リスク：利用しているクラウドサービス（Amazon RDS・Azure Database for MySQL等）のManaged版も順次EOLを迎えます。
EOLが目前に迫る中、十分な検証期間を確保できないまま移行を進め、インシデントを招くケースが増えています。今この瞬間からでも影響範囲の把握と対策に着手することが、リスク最小化の鍵となります。
MySQL 8.4の新機能と重要な変更点
MySQL 8.0→8.4では、単なるバグ修正にとどまらず、セキュリティ・パフォーマンス・レプリケーションの3領域にわたる重要な仕様変更が行われました。影響範囲が広い順に解説します。
▼ セキュリティ・認証
【要対応】mysql_native_passwordがデフォルト無効化──接続障害を防ぐ影響チェックと移行手順
MySQL 8.4では、mysql_native_passwordがデフォルトで無効化されました。
そのため、8.0からそのままアップグレードすると、該当ユーザーがログインできなくなる可能性があります。
対応の基本方針は「認証プラグインを caching_sha2_password へ移行する」ことです。
移行期間中の暫定措置として一時的に有効化する方法もありますが、最終的には新しい認証方式への切り替えが必要です。アプリケーション側の接続設定変更も合わせて確認してください。
影響を受けるユーザーの確認方法・具体的なコマンド・設定手順については、以下の記事をご参照ください。
WindowsでSASL/LDAP認証が正式対応──Kerberos連携でActive Directory統合がついに実現
MySQL 8.4では、Windows環境でのSASLベースのLDAP認証が正式にサポートされました。これによりWindowsクライアントからGSSAPI/Kerberosを使った認証が可能になります。
MySQL 8.3.0（Innovation リリース）でWindowsへの対応が初めて実現し、MySQL 8.4（LTS）においても正式に利用可能です。
Windowsサーバー上でサポートされていなかった機能（macOS等非Windowsプラットフォームでは対応済み）がようやくWindowsにも対応しました。
▼ パフォーマンス・InnoDB
InnoDBデフォルト値が20項目以上変更──innodb_io_capacityが200→10,000になる実務的な意味
MySQL 8.4では、InnoDBに関連するシステム変数のデフォルト値が20項目以上にわたって変更されました。これは「アップグレードしただけでパフォーマンスが変わる」ことを意味するため、my.cnfでの明示的な設定値を持たない環境は特に注意が必要です。
主な変更の方向性としては、I/O性能の上限引き上げ・ログバッファの拡張・フラッシュ方式の最適化・多コアCPUへの自動スケールなどが挙げられます。
特に innodb_io_capacity（200→10,000）の変更は、SSD環境での書き込み性能に大きく影響します。
一方、innodb_adaptive_hash_index がデフォルト OFF になった点はワークロードによっては性能低下を招く可能性があるため、アップグレード後の負荷テストが推奨されます。
ログバッファと一時テーブルのメモリ割り当てが自動最適化──固定1GBから「搭載メモリの3%」へ
temptable_max_ram（一時テーブルが使用できるメモリの上限）のデフォルト値が、固定の1GiBから「搭載メモリの3%（最小1GiB〜最大4GiB）」へと変更されました。
8.0では搭載メモリが128GiBあっても上限は1GiBに固定されていたため、大規模な集計クエリやJOINが多い環境では一時テーブルがディスクにあふれやすい状況でした。8.4ではサーバーのメモリリソースを適切に活用できるようになり、大量データを扱うバッチ処理やBI系クエリのパフォーマンス改善が期待できます。
またinnodb_log_buffer_sizeも16MiBから64MiBへ拡張されました。書き込みが集中するトランザクションが多い環境では、ログバッファの拡張によりI/O待ちが減少します。
参照先：詳細な動作仕様について
▼ レプリケーション
タグ付きGTID（UUID:TAG:NUMBER）が新設──データ操作と管理操作のトランザクションを識別できるように
MySQL 8.4では、GTIDのフォーマットが拡張され、トランザクションにタグを付与できるようになりました。これにより「データ操作」と「管理操作（DDLなど）」を区別して追跡できるようになり、レプリケーション遅延の原因特定やポイントインタイムリカバリの精度向上が期待できます。
タグ付きGTIDの使用には新しい権限が必要です。8.0からのアップグレード時の権限付与ルールや、既存レプリケーション設定への影響については以下の記事で詳しく解説されています。
MTA（マルチスレッドアプライヤ）がSQL_AFTER_GTIDSに対応──レプリカ遅延からの高速回復がようやく実現
MySQL 8.0では、特定のGTIDへの追いつき処理（SQL_AFTER_GTIDS オプション使用時）にマルチスレッドアプライヤ（MTA）が使えないという制限がありました。
MySQL 8.4ではこの制限が撤廃され、大幅な遅延状態からの回復をマルチスレッドのまま実行できるようになりました。フェイルオーバー後やメンテナンス後の同期速度が大幅に向上します。
技術的な詳細は公式ドキュメントをご確認ください。
▼ 廃止・削除
【完全削除】MASTER/SLAVE構文が使用不可に──コード・設定ファイルの棚卸しが必須な理由
MySQL 8.0で「非推奨」とされていた MASTER/SLAVE 系の構文・システム変数・関数が、MySQL 8.4で完全に削除されました。これらをアプリケーション・シェルスクリプト・監視ツールで使用している場合、アップグレード後にエラーが発生します。
移行先の代替構文（SOURCE/REPLICA 系）への置き換えが必須です。なお、mysqldump には後方互換のためのオプションが追加されており、旧構文を含むダンプファイルの移行にも活用できます。
移行手順の詳細は以下をご覧ください。
「旧レプリケーション用語（MASTER/SLAVE）」置き換えの全対象リストと対処法
MASTER/SLAVEの完全削除と関連して、センシティブキーワードの置き換えが必要です。単純なSQL構文の置き換えだけでなく、以下も対象になります。
– 監視ツールの設定ファイル（Zabbix・Nagios・Prometheus exporterなど）
– バックアップスクリプトのSQL文
– アプリケーションのレプリケーション制御コード
– CI/CDパイプラインのDB操作スクリプト
対象となる変数・関数・ステートメントの全リストと具体的な置き換え例については、以下の詳細解説をご参照ください。
▼ その他の変更
Cloneプラグインの柔軟化──バージョン制約の緩和で運用がどう変わるか
MySQL 8.0.36以前では、Cloneプラグインを使ったデータのコピーにパッチバージョンまで一致が必要でした（例：8.0.32から8.0.33へのCloneは不可）。この制約はMySQL 8.0.37（2024年4月30日）以降の8.0.x系でも緩和されています。
MySQL 8.4ではこの制約が緩和され、メジャー・マイナーバージョンが同じであればパッチバージョンが異なっていても使用可能になりました（例：8.4.0→8.4.14へのCloneが可能）。
これにより、バージョンを揃えるための余分な作業ステップが減り、レプリカ追加・再構築・バックアップからのリカバリ作業がより柔軟に行えるようになります。
【資料ダウンロード】MySQL 8.0→8.4の変更点をまとめて確認する
MySQL 8.0→8.4の移行では、確認すべき変更点が認証・InnoDB・レプリケーション・構文と多岐にわたります。主要な互換性の変更点を1枚にまとめたホワイトペーパーを無料公開していますので、移行前のチェックリストとしてご活用ください。
【ホワイトペーパー】MySQL 8.0→8.4LTS移行前互換性まとめ
MySQL 8.0 → 8.4 アップグレードの注意点と手順
アップグレード前の確認事項
アップグレードを始める前に、少なくとも以下3点のリスクを把握しておく必要があります。
① 非互換の構文・変数によるアプリ停止
MASTER/SLAVE系構文の完全削除は、レプリケーションを使用するほぼすべての環境に影響する重要な変更の一つです。コードベースとスクリプト類を事前に棚卸しし、完全に置き換えてからアップグレードに進みます。
② InnoDBデフォルト値変更による想定外の挙動変化innodb_adaptive_hash_indexのOFF化など、一部の変更は検証環境で実ワークロードをテストするまで影響が見えません。本番と同等の負荷をかけた検証が必要です。
③ mysql_native_password無効化による接続障害
アップグレード直後にアプリが接続できなくなるという典型的なインシデントです。事前にmysql.userテーブルの認証プラグインを全件確認してください。
移行作業の大まかな流れ──事前準備・本番移行・事後確認
アップグレードは大きく4フェーズで進めます。
1. 互換性チェック：MySQL Shellのutil.checkForServerUpgrade()を使って非互換箇所を自動検出する
2. バックアップ取得：論理バックアップ（mysqldump）と物理バックアップの両方を取得する。物理バックアップには MySQL Enterprise Backup（Enterprise版のみ）やPercona XtraBackup（無償OSS）が利用可能
3. 検証環境でのテスト：本番データのコピーを使い、実際のワークロードでアップグレード後の挙動を確認する
4. 本番移行・事後確認：計画されたメンテナンスウィンドウで実施し、完了後はレプリケーション状態・エラーログ・クエリパフォーマンスを重点確認する
詳細な手順と注意点は専門解説記事で確認する
各フェーズの具体的な実行コマンド・パラメータ設定・よくあるトラブルと対処法を詳しく解説した専門記事を用意しています。アップグレードの実作業を進める前に、必ずご一読ください。
参照先：MySQLバージョンアップの手順・注意点｜安全に進めるポイントを解説
MySQL 8.0から8.4への移行に不安がある場合は
自社だけで進めるのが難しいケース
MySQL 8.0→8.4のアップグレードは、適切な準備と知識があれば自社で対応可能です。しかし以下のような状況では、専門家のサポートを検討することを強くお勧めします。
– 長年の運用でコードベースへのMASTER/SLAVE系構文の混入箇所が把握できていない
– アップグレードをテストできる検証環境がない、または本番と乖離している
– DBAが不在または兼任で、アップグレードに割ける工数が限られている
– 2026年4月のEOLまでの時間が限られており、リスクを取れない
– Amazon RDS・Azure Database for MySQL等のマネージドサービスを使っており、クラウド特有の手順に不安がある
パソナデータ＆デザインが支援できること
パソナデータ＆デザイン（旧スマートスタイル）は、MySQLのコンサルティング・サポートにおいて国内20年以上の実績を持つOracle認定パートナーです。MySQL専門エンジニアが、アップグレードの全フェーズをサポートします。
支援内容の例
– 現行環境の非互換チェックと影響箇所の洗い出し
– アップグレード計画の策定（スケジュール・リスク評価）
– 検証環境の構築と実ワークロードでのテスト支援
– 本番移行作業の立会い・サポート
– 移行後のパフォーマンスチューニングとモニタリング設計
– MySQL商用ライセンス（Oracle公式サポート）の調達・契約
まずは現状整理からご相談ください
「自社環境でどんな対応が必要かわからない」という段階からでも対応しています。現在の環境情報をお聞きした上で、必要な対応範囲と工数感を整理するところからご支援します。お気軽にお問い合わせください。
[MySQL 8.X アップグレード支援サービスの詳細・お問い合わせ]
まとめ
MySQL 8.0のEOLは2026年4月30日です。移行計画の策定・検証・本番適用を経ると、今から着手しても余裕のないスケジュールです。
8.4への移行で対応が必要な主なポイントは、
・認証プラグイン（mysql_native_passwordのデフォルト無効化）
・構文変更（MASTER/SLAVE系の完全削除）
・InnoDBデフォルト値の大幅変更
の3点です。いずれも事前の確認と準備なしにアップグレードするとインシデントに直結します。不安な点があれば、専門家への相談を早めに検討してください。
