MySQL 8.0以降では、AES_ENCRYPTとAES_DECRYPTでAES-GCMモードをサポートするようになり、このモードでは暗号化に初期化ベクトル（IV）が内部的に使用されます。ただし、IVをユーザーが直接指定することはできません。
現時点では、MariaDBはAES-GCMモードをサポートしていません。
MySQL 8.0以降では、AES_ENCRYPTおよびAES_DECRYPT関数でAES-GCMモードを利用する際、追加のオプションを指定することで有効化できます。
SET block_encryption_mode = 'aes-256-gcm'; -- 暗号化モードをAES-GCMに設定 SELECT AES_ENCRYPT('テキスト', '鍵');
SET block_encryption_mode = 'aes-256-gcm'; -- 同じ暗号化モードを設定 SELECT AES_DECRYPT(暗号化されたデータ, '鍵');
AES-GCMモードを使用する場合、暗号化されたデータは初期化ベクトル（IV）や認証タグの追加により、元のデータよりもサイズが増加します。
暗号化データの合計サイズの増加は以下の通り：
12バイト（IV） + 16バイト（認証タグ） = 28バイトの増加。
IVの役割について
初期化ベクトル（IV）は、暗号化アルゴリズム（特にAES-CBCなどのブロック暗号モード）において、暗号化の際に予測可能性を排除し、同じ平文でも異なる暗号文を生成するために使われます。これにより、暗号化の安全性が向上します。
キーを変えることでも「同じ平文でも異なる暗号文を生成する」。
キーを変える場合
キーを変えることで異なる暗号文が生成されます。これは、暗号化アルゴリズムにおいて暗号文がキーに依存するためです。
メリット:
毎回異なるキーを使うことで、同じ平文でも完全に異なる暗号文が得られ、予測可能性を排除できます。
デメリット:
キー管理が複雑になる: 多くの異なるキーを管理する必要があるため、特に大規模システムでは運用が困難になります。
キー共有の課題: 復号化のために暗号化と同じキーを安全に相手と共有する手段が必要です。
IVを使う場合
IV（初期化ベクトル）は、固定されたキーを使い続けても平文が同じ場合に暗号文を異なるものにするための手段として設計されています。IVはランダムに生成され、通常、暗号文と一緒に保存または伝達されます。
メリット:
キーを変えなくても効果を得られる: 固定された1つのキーで運用でき、管理が容易になります。
アルゴリズム的なセキュリティ強化: 平文のパターンが暗号文に現れることを防ぎます（例：AES-CBC、AES-GCM）。
デメリット:
IV自体がランダムである必要があるため、その生成プロセスやストレージに注意が必要です。