はじめに
2026年4月のMySQL 9.7リリースが近づいてきました。
すでにEarly Access（EA）版も公開されており、正式リリースに向けた準備が進められています。
これまでのアップデートでは VECTOR 型の導入やベクトル検索の強化などAI関連の機能を含むさまざまな追加機能がありましたが、9.7でも可観測性の向上（レプリケーション統計やフロー制御のモニタリング）、OpenTelemetry 連携など、運用・開発の両面で機能が追加されています。
一方で、新機能に目が向きがちですが、アップグレード時には運用面で影響が出る可能性があるため、非推奨・削除・挙動変更といった変更にも注意が必要です。
本記事では、9.0〜9.6のリリースノートをあらためて振り返り、運用面で注意が必要と考えられる非推奨・削除・挙動変更について整理しました。
アップグレード時の注意点を確認する際のヒントになれば幸いです。
※本記事は執筆時点で公開されているリリースノートをもとにまとめたものであり、将来の仕様は変更される可能性があります。適用前には必ず公式ドキュメントをご確認ください。
また、ここで取り上げている内容は筆者が運用上気になった点を中心に抜粋したもので、すべての変更点を網羅しているわけではありません。
🔐 認証・権限管理系
mysql_native_password 削除（9.0）
MySQL 9.0ではmysql_native_password認証プラグインが完全に削除されました。
この認証方式はMySQL 8.1から既に非推奨とされており、caching_sha2_passwordへの移行が推奨されていました。
これまではプラグインを有効化することで引き続き利用することも可能でしたが、MySQL 9.0では機能自体が削除されたため利用できなくなります。
実際に認証プラグインの一覧を確認すると、MySQL 8.4ではmysql_native_passwordが表示されますが、MySQL 9.0以降では一覧から削除されていることが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
MySQL 8.4.8> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_TYPE = 'AUTHENTICATION'; +-----------------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +-----------------------+---------------+ | sha256_password | ACTIVE | | caching_sha2_password | ACTIVE | | mysql_native_password | DISABLED | +-----------------------+---------------+ MySQL 9.6.0> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_TYPE = 'AUTHENTICATION'; +-----------------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +-----------------------+---------------+ | sha256_password | ACTIVE | | caching_sha2_password | ACTIVE | +-----------------------+---------------+ |
現在のユーザーが使用している認証プラグインは、以下のSQLで確認できます。
|
1 |
SELECT user, host, plugin FROM mysql.user; |
plugin列がmysql_native_passwordのユーザーは、MySQL 9.0以降では接続時にエラーとなるため注意が必要です。
FLUSH PRIVILEGES 関連機能の非推奨化（9.2）
MySQL 9.2では、ユーザー権限テーブルの再読み込みに使用されてきたFLUSH PRIVILEGESステートメントが非推奨となりました。
実行すると警告が表示され、将来のバージョンで削除される予定です。
また、FLUSH PRIVILEGESに関連する以下の機能も非推奨となり、使用すると警告が出力されます。
FLUSH_PRIVILEGES権限mysqladmin flush-privilegesmysqladmin reload
警告は出ませんが、次の権限リロード手法も非推奨扱いとなりました。
SIGHUPシグナルによる権限リロードmysqladmin refreshによる権限リロードFLUSH PRIVILEGESによるcaching_sha2_passwordキャッシュのリフレッシュ
実際にFLUSH PRIVILEGESを実行すると、以下のようなWARNINGが表示されます。
|
1 2 3 4 5 6 7 8 9 10 |
FLUSH PRIVILEGES; Query OK, 0 rows affected, 1 warning (0.003 sec) SHOW WARNINGS; +---------+------+---------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------------------------------------------+ | Warning | 1681 | 'FLUSH PRIVILEGES' is deprecated and will be removed in a future release. | +---------+------+---------------------------------------------------------------------------+ 1 row in set (0.000 sec) |
従来の運用手順書や自動化スクリプトでは、権限変更時にFLUSH PRIVILEGESを実行する例もありました。
しかし現在のMySQLでは、権限変更時に権限テーブルが自動的に更新されるため、通常はFLUSH PRIVILEGESを実行する必要はありません。
そのため、既存の運用スクリプトにFLUSH PRIVILEGESが含まれていないかの確認が必要になります。
⚙️ SQL / DDL / Optimizer系
列定義内の外部キーが正しく外部キー制約として適用されるように修正（9.0）
MySQLではこれまで、列定義内で記述した外部キーが正しく外部キー制約として認識されず、意図した参照整合性が確保されないことがありました。
例えば、次のような親テーブルpersonを作成します。
|
1 2 3 4 |
CREATE TABLE person ( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, name CHAR(60) NOT NULL ); |
続いて、子テーブルshirtを列定義内でREFERENCES句を使った外部キー定義で作成します。
|
1 2 3 4 |
CREATE TABLE shirt ( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, owner SMALLINT UNSIGNED NOT NULL REFERENCES person(id) ); |
MySQL 8.4以前では、この構文はSQLとしては受理されるものの外部キー制約は作成されませんでした。
つまり、REFERENCES句を記述しても実際には無視されていました。
しかしMySQL 9.0以降では、列定義内で記述したREFERENCES句が正しく解釈され、外部キー制約として作成されるようになりました。
また、参照列を省略した場合（REFERENCES person）は、親テーブルのPRIMARY KEYが自動的に参照されます。
実際にテーブル定義を確認すると次のような違いが確認できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
MySQL 8.4.8> SHOW CREATE TABLE shirt\G *************************** 1. row *************************** Table: shirt Create Table: CREATE TABLE `shirt` ( `id` smallint unsigned NOT NULL AUTO_INCREMENT, `owner` smallint unsigned NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec) MySQL 9.6.0> SHOW CREATE TABLE shirt\G *************************** 1. row *************************** Table: shirt Create Table: CREATE TABLE `shirt` ( `id` smallint unsigned NOT NULL AUTO_INCREMENT, `owner` smallint unsigned NOT NULL, PRIMARY KEY (`id`), KEY `owner` (`owner`), CONSTRAINT `shirt_ibfk_1` FOREIGN KEY (`owner`) REFERENCES `person` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.000 sec) |
この変更により、MySQL 8.4以前では問題なく実行できていたSQLが、MySQL 9.0以降では外部キー制約違反としてエラーになる可能性があります。
|
1 2 3 4 5 |
MySQL 8.4.8> INSERT INTO shirt VALUES (1, 999); Query OK, 1 row affected (0.01 sec) MySQL 9.6.0> INSERT INTO shirt VALUES (1, 999); ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test`.`shirt`, CONSTRAINT `shirt_ibfk_1` FOREIGN KEY (`owner`) REFERENCES `person` (`id`)) |
そのため、アプリケーションやスキーマ管理ツールが生成するDDLに列定義内で記述されたREFERENCES句が含まれていないかを事前に確認しておくことを推奨します。
また、MySQL 8.4以前ではREFERENCES句が記述されていても実際には外部キー制約が作成されていない可能性があります。
そのため、既存テーブルについても、意図した外部キー制約が作成されているか、SHOW CREATE TABLEなどで合わせて確認しておくことを推奨します。
ER_SUBQUERY_NO_1_ROW が IGNORE で無視されなくなる（9.0）
MySQLでは、INSERT IGNOREやUPDATE IGNOREなどIGNOREを使用した場合、一部のエラーが警告に変換されて処理が継続されます。
MySQL 8.4以前では、スカラーサブクエリが複数行を返すエラー（ER_SUBQUERY_NO_1_ROW）もIGNOREによって無視されていました。
しかし、MySQL 9.0以降では、このエラーはIGNOREの対象外となり、常にエラーとして扱われるようになりました。
例えば、以下のような2つのテーブルを作成します。
|
1 2 3 4 5 6 7 8 9 |
CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(50) ); CREATE TABLE orders ( id INT PRIMARY KEY, user_id INT NOT NULL ); |
次にusersテーブルにデータを挿入します。
|
1 |
INSERT INTO users VALUES (1,'Alice'), (2,'Bob'); |
ここでordersテーブルにIGNOREを含めたINSERT文を実行します。
|
1 |
INSERT IGNORE INTO orders VALUES (1, (SELECT id FROM users)); |
このサブクエリはusersテーブルのidを取得するため、2行の結果を返します。
MySQL 8.4以前とMySQL 9.0以降では次のように挙動が異なります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
MySQL 8.4.8> INSERT IGNORE INTO orders VALUES (1, (SELECT id FROM users)); MySQL 8.4.8> SHOW WARNINGS; +---------+------+----------------------------------+ | Level | Code | Message | +---------+------+----------------------------------+ | Warning | 1242 | Subquery returns more than 1 row | | Warning | 1048 | Column 'user_id' cannot be null | +---------+------+----------------------------------+ MySQL 8.4.8> SELECT * FROM orders; +----+---------+ | id | user_id | +----+---------+ | 1 | 0 | +----+---------+ ※データは挿入されているが、user_idにはNOT NULL列の暗黙デフォルト値（0）が設定されている MySQL 9.6.0> INSERT IGNORE INTO orders VALUES (1, (SELECT id FROM users)); ERROR 1242 (21000): Subquery returns more than 1 row MySQL 9.6.0> SELECT * FROM orders; Empty set (0.000 sec) ※データが挿入されていない |
この変更もMySQL 8.4以前では問題なく実行できていたSQLが、MySQL 9.0以降ではエラーになる可能性があります。
そのため、IGNOREを使用したDML文ではサブクエリが必ず1行のみ返すことを確認してください。
また、MySQL 8.4以前ではIGNOREによってエラーが警告に変換されることで、意図しない値が挿入されている可能性もあります。
そのため、既存データについても想定外の値が挿入されていないか確認しておくことを推奨します。
JSON_TABLE のパス検証が厳格化（9.3）
MySQL 9.3ではJSON_TABLE()のJSONパス検証が厳格化されました。
MySQL 9.2以前では、無効なJSONパスを指定した場合でも警告として処理されていましたが、MySQL 9.3以降ではエラーとして扱われるようになりました。
そのため、JSON_TABLE()を使用しているSQLがある場合、JSONパスの指定が正しいか事前に確認しておくことを推奨します。
外部キーのカスケード処理の実装変更（9.6）
MySQL 9.6では、外部キー制約およびON DELETE CASCADE/ON UPDATE CASCADEの処理がInnoDBストレージエンジンからMySQLサーバーのSQL層に移動しました。
この変更により、外部キーによって実行された子テーブルの変更もバイナリログに記録されるようになり、データ変更の可視性や分析機能が向上しています。
従来のInnoDBによる処理を使用する場合は、innodb_native_foreign_keysシステム変数を設定してサーバーを起動することで従来の動作に戻すことが可能です。
🧩 プラグイン・コンポーネント系
AES-ECB 削除 （9.1）
MySQL 9.1では、keyring関連コンポーネントからAES-ECB（Electronic Codebook）モードのサポートが削除されました。
AES-ECBは暗号学的に安全ではない方式として知られており、セキュリティ強化の観点から削除されています。
そのため、アプリケーション側でECBモードを前提とした暗号処理を実装している場合は互換性に影響する可能性があるため注意してください。
keyring_aws プラグイン非推奨（9.1）
MySQL 9.1では、AWS Key Management Service（AWS KMS）と連携するkeyring_awsプラグインが非推奨となりました。
代わりに、新しいcomponent_keyring_awsコンポーネントが導入されており、今後はこちらの利用が推奨されます。
keyring_awsプラグインは将来のバージョンで削除される予定のため、現在利用している環境ではcomponent_keyring_awsへの移行を検討する必要があります。
version_tokens プラグインの非推奨化（9.2）
MySQL 9.2では、version_tokensプラグインが非推奨となりました。
これに伴い、version_tokensプラグインを使用する機能や関連する関数を使用した場合に非推奨警告が出力されるようになりました。
そのためversion_tokensプラグインを利用している環境では注意が必要です。
MD5 / SHA1 関数のコンポーネント化（9.6）
MySQL 9.6ではMD5()およびSHA1()のSQL関数がセキュリティと柔軟性強化のため別コンポーネントに移行しました。
これらの関数はデフォルトでは利用できず、使用する場合はclassic_hashingコンポーネントをインストールする必要があります。
そのため、アプリケーション側でMD5()やSHA1()を使用している場合は、MySQL 9.6以降では関数が存在せずエラーとなるため注意が必要です。
まとめ
本記事では、MySQL 9.0〜9.6のリリースノートに含まれる非推奨・削除・挙動変更の主な項目についてまとめました。
MySQL 9.0以降では、これまで問題なく動作していたSQLや設定が影響を受ける可能性があります。
そのため、アップグレードを行う際は本記事で紹介した変更点を中心に、影響の有無を事前に確認しておくことが重要です。
MySQLのバージョンアップに伴う影響調査や事前診断が必要な場合は、お気軽にお問い合わせください。
