Aurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違い

こんにちは。アンドパッドでDBREを務めてます久保と申します。こちらは ANDPAD Advent Calendar 2025 の24日目の記事です。

今日はAurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違いについてお話しします。

背景

現在DBREではAurora MySQLのバージョンアップ（3.04.2→3.10.0）の準備をしています。その準備の中で、開発環境のAurora MySQLのバージョンアップを実施しました。その際に、バージョンアップを実施した一部のクラスターのFreeableMemoryが急激に落ち始める事象が発生しました。

そこで、performance_schema.memory_summary_global_by_event_nameテーブルで現在割り当てられているメモリーの集計サイズを確認したところ、バージョンアップ前に比べてperformance_schema.accountsとperformance_schema.hostsのレコードが大量に作成されていることが確認されました。

その理由をはっきりさせるためにAWSサポートにこの事象の原因を伺いました。その結果、db.t4g.mediumインスタンスクラスではバージョン前後で以下の違いがあることが分かりました。

Aurora MySQL 3.04.2: Performance Schemaは自動管理されない
Aurora MySQL 3.10.0: Performance Schemaが自動管理される

つまり、db.t4g.mediumインスタンスクラスでは以下のようにPerformance Schemaは自動管理されない設定にも関わらず、Aurora MySQL 3.10.0では自動管理が適用されてしまうのです。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html#USER_PerfInsights.EnableMySQL.options

これにより、リソースに適用されるパラメータ値、特にperformance_schema_accounts_sizeとperformance_schema_hosts_sizeに関して以下のような違いが発生し、Performance Schemaへの記録量が増えてしまい、FreeableMemoryを消費してしまったということが分かりました。

Aurora MySQL 3.04.2: 0 (テーブル内のステータス変数情報を保持しない)
Aurora MySQL 3.10.0: -1 (自動スケーリング)

この事象の調査をきっかけにPerformance Schemaの手動管理と自動管理の違いについて学びが得られたので、今回ブログにまとめることにしました。

Performance SchemaとPerformance Insights

Performance SchemaはMySQLで実行されるクエリやトランザクションなどの情報を記録する機能になります。実際performance_schemaデータベースに様々なテーブルがあり、そこからどこがボトルネックになっているか分析することができます。

Performance InsightsはAurora MySQLの機能であり、Performance Schemaで収集された情報を見やすく提供されたものになります。そのため、これら二つの機能は関連があり、後述するPerformance Schemaの自動管理に影響します。

いずれも便利な機能ではありますが、下記のようにPerformance Schemaの情報はメモリ上で保持され、TRUNCATEしてもメモリは解放されないことに注意が必要です。

https://dev.mysql.com/doc/refman/8.0/ja/performance-schema-memory-model.html

Performance Schemaの自動管理

Aurora MySQLのパラメータにはperformance_schemaというパラメータが存在します。この値が0の時、「Performance Schemaの自動管理」という状態になります。これはPerformance Insights を有効にした状態でDBインスタンスを作成すると自然にこの状態になります。「Performance Schemaの自動管理」という状態を端的に述べると、「Performance Insightsで使用するためのPerformance Schemaの情報をよしなに収集する」ように設定された状態を指します。

Aurora MySQLのPerformance Schema関係のパラメータ（performance_schema_%）は数多く存在します。これをPerformance Insightsでの監視がしやすくなるように自動的に設定してくれるのが「Performance Schemaの自動管理」であり、公式でもこれを推奨しています。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.EnableMySQL.html#USER_PerfInsights.EnableMySQL.options

ただし、Performance Insightsの都合のいいように設定されている訳なので、「Performance Schemaの自動管理」をしている状態では、Performance Schema関係のパラメータ（performance_schema_%）を更新しても適用されないので注意が必要です。

また、db.t4g.mediumインスタンスクラスでは自動管理はサポートされてないのでこれも注意が必要です。ただし、背景にも記述したように、Aurora MySQL 3.10.0のバージョンでは自動管理される設定になってしまいます。

Performance Schemaの手動管理

performance_schemaというパラメータが1の状態の時、「Performance Schemaの手動管理」という状態になります。先ほどの「Performance Schemaの自動管理」とは逆に、Performance Schema関係のパラメータ（performance_schema_%）を自分で編集できるようになった状態のことを言います。

例えば、背景に記述した事象のようなことが起こり、何かしらのPerformance Schema関係のパラメータ（今回の場合はperformance_schema_accounts_sizeとperformance_schema_hosts_size）を更新する必要がある場合は、performance_schemaというパラメータを1にした上で該当のPerformance Schema関係のパラメータを更新することになります。

ただし、手動管理にしてPerformance Schema関係のパラメータをいじったことにより、Performance Insightsの一部機能が見れなくなってしまう可能性があるので注意が必要です。また、performance_schemaを更新する際は再起動が必須になるので注意が必要です。

まとめ

今回はPerformance Schemaの手動管理と自動管理について述べました。基本的にAWS公式が言及しているようにPerformance Schemaは自動管理で問題ないと思います。ただし、今回のようにメモリを圧迫するような事象が発生した場合は、手動管理にした上で微調整が必要になります。その際はこの記事が助けになれば幸いです。