はじめに

皆さんご存知の通りMySQL8.0では多くの機能変更が施されています。その中の一つに「ステータス変数（SHOW GLOBAL STATUSで確認できるもの）」の追加・廃止があります。

本番環境でMySQL運用をされている方は、監視ツールもしくは独自のスクリプトなどで日々ステータス変数を収集しているかと思います。そんな中、8.0における変更内容を把握しておかないと従来作成していたグラフがエラーになる、または有用なステータス情報を見落としてしまう可能性があります。

そこで本稿ではMySQL5.7.29とMySQL8.0.19を比較して、8.0から追加された、もしくは廃止されたステータス変数について取り上げてみたいと思います。

追加されたステータス変数

一覧

各ステータス変数の解説

MySQL8.0のステータス変数に関する公式マニュアルはこちらにあります。

Acl_cache_items_count

キャッシュされた権限オブジェクトの数を示しています。ここでいう権限オブジェクトとは、ユーザとそこに付与されたアクティブなロールの組み合わせのことです。
ロールをかなり頻繁に使用する環境でもなければ、監視の必要性は低いでしょう。

Caching_sha2_password_rsa_public_key

MySQL8.0から実装された caching_sha2_password 認証ブラグインが、RSAキーペアベースのパスワード交換のために使用する公開鍵の内容が表示されます。
caching_sha2_password_public_key_pathシステム変数で指定した公開鍵ファイルが参照されます。
原則、監視する必要はないかと思います。

Com_*** 系

Com_xxx ステータス変数は、「xxx」に該当するコマンド（クエリ）がMySQL上で実行された回数（累積値）を示しています。
8.0から追加された新機能に関連するコマンドのカウンタが追加されていることが分かります。
→ Com_create_role, Com_clone, Com_alter_resource_group など

これらのコマンドは常日頃から実行されるものではないことが多いので、常時監視対象とする必要はないかもしれませんが、システムの特質によって頻繁に実行し得るコマンド（set passwordなど）がある場合は、変数の増分を監視した方が良いかと思います。

Current_tls_*** 系

サーバ・クライアント間のTLS通信を行っている場合に、そのステータス情報を表示します。
昨今のセキュリティを取り巻く情勢を踏まえ、MySQLの通信暗号化を利用するケースが増えていくことが予想されます。そうした場合に、設定が正常にできているか、正しく暗号化が動作しているかをこのステータス変数を使って確認してください。
ただし、動的に変わる変数はないので常時監視する必要性は薄いと思います。

Innodb_*** 系

「Innodb_」で始まるステータス変数は、その名の通りInnoDBストレージエンジンに関するステータスを扱っています。MySQL8.0ではInnoDBの大幅な機能改善がなされており、それに伴ってステータス変数も追加されています。

※ なお、下記2つのステータス変数が追加されたことは、リリースノートに記載があります

• Innodb_sampled_pages_read / Innodb_sampled_pages_skipped

MySQL8.0.19で追加されたステータス変数で、ヒストグラム統計のための効率的なサンプリングに関連しています。
従来のMySQLのサンプリング方式ではテーブル全体をスキャンする必要があり、巨大なテーブルではコストがかかっていました。そこで、InnoDBに実装されたサンプリングではテーブルスキャンを回避し、ヒストグラムの生成が容易になりました。
このステータス変数ではサンプリングの挙動をモニタリングできます。統計情報の挙動にシビアな環境では、監視してみても良いかと思います。

• Innodb_system_rows_read / inserted / deleted / updated

上記と同じくMySQL8.0.19で追加されました。8.0からMySQLが作成するシステムテーブルのストレージエンジンが全てInnoDBになりましたが、そのシステムテーブルに対する参照・挿入・削除操作の件数を表示するためのステータス変数です。
基本的にシステムテーブルへの操作は頻繁に行われるものではありませんが、「relay_log_info_repository or master_info_repository=TABLE」を設定している環境ではレプリケーションの情報がシステムテーブル(*1)に保存されるため、InnoDBテーブル関連のカウンタ（Innodb_rows_readなど）に影響が出てしまうケースがありました。
そこで、この新しいカウンタの数値を全体から引くことで、より現実的なステータス変数の監視が可能になりました。もし、監視ツールなどでInnoDB行への操作を可視化している場合は、全体から Innodb_system_rows_*** ステータス変数の数値を引いた方が良いでしょう。

*1 : slave_master_info, slave_replay_log_info, slave_worker_info テーブルを指します

• Innodb_undo_tablespaces_active / explicit / implicit / total

MySQL8.0から、Undoログの管理が非常にフレキシブルになりました（参考記事）。端的に言えばオンラインでUndoログの拡張・縮小が可能となり、MySQL8.0.14からはSQL（CREATE UNDO TABLESPACE）での操作もできるようになりました（参考記事）。

上記のようなUndoログの機能改善に伴い、ステータス変数も新たに追加されました。Innodb_undo_tablespaces_implicitはInnoDBが内部的に作成した数で、対するInnodb_undo_tablespaces_explicitはユーザが手動で作成した数を示しています。Innodb_undo_tablespaces_activeは両者のうちアクティブな領域を示しており、これを total から引くことで非アクティブな領域も算出できます。

Mysqlx_*** 系

Mysqlx_xxxステータス変数は、mysqlxプラグイン関連のステータス変数です。公式ドキュメントはこちらです。

mysqlxプラグインとは、従来のMySQLプロトコルでは対応できなかった操作を可能にする「Xプロトコル」を受け付けるための機能です。逆にクライアント側にはX DevAPIと呼ばれるAPIが用意され、Java, .Net, Node.js, Pythonなどがサポートされています。

Server側のmysqlxプラグインとクライアント側のX DevAPIを組み合わせることで、MySQLを「ドキュメントデータベース」として利用できます。即ち、従来のRDB用途ではなくMySQLをNoSQLとして扱い、JSON型などスキーマレスなデータを蓄積・処理することが実現できます。

※ 弊社ブログでも過去の記事で取り上げています

Xプロトコル自体はMySQL5.7で追加された機能でしたが、MySQL 8.0になって上記のMySQL Document Storeが正式にGAになったことで、多くのステータス変数が追加されました。

もしXプロトコルを実運用する場合は、これらのステータス変数を監視することを推奨します。

【主な変数】

• Mysqlx_bytes_received / Mysqlx_bytes_sent
  mysqlxプラグインが受信・送信した累計のデータ量

• Mysqlx_connection_accept_errors / errors / accepted / closed / rejected
  mysqlxプラグインへの接続・切断・接続エラーの件数

• Mysqlx_crud_***
  mysqlxプラグイン上でのCRUD操作、すなわちCREATE、READ、UPDATE、DELETEの実行件数
  ドキュメントデータベース上での操作を可視化するのに有効でしょう

• Mysqlx_stmt_***
  CREATE COLLECTIONステートメントや KILL CLIENT ステートメントの実行件数

Performance_schema_session_connect_attrs_longest_seen

クライアントが、MySQLサーバのPerformance_Schemaに対して64KB以上の接続属性データを送信しようとした時に、サーバはそれを拒否します。この時、Performance_schema_session_connect_attrs_longest_seen変数に、その拒否されたデータのサイズが記録されます。
DBAは、このステータス変数の数値を見て、performance_schema_session_connect_attrs_size 変数の設定値を引き上げるか、どのクライアントが巨大なデータを送信しているのかを調査・改善することが推奨されます。
詳しくはマニュアルにも記載があります。

Secondary_engine_execution_count

MySQL8.0.13で追加されましたが、「For future use.」なので詳細不明です。
“セカンダリエンジン” なので、ストレージエンジンが複数設定できるようになるのでしょうか…？

廃止されたステータス変数

一覧

各ステータス変数の解説

Com_alter_db_upgrade

ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME コマンドの実行回数を表示します。MySQL8.0では “UPGRADE DATA DIRECTORY NAME” 句が使えなくなったため、同ステータス変数も削除されました。

Innodb_available_undo_logs

使用可能な InnoDB undo ログの数を示していましたが、上記の通りUndoログは動的な管理が可能になりましたので、このステータス変数も不要となります。

Qcache_***

クエリキャッシュ関連のステータス変数です。MySQL8.0ではクエリキャッシュ機能自体が無くなったため、ステータス変数も全て削除されました。

おわりに

今回紹介したステータス変数の変化だけを見ても、MySQL8.0が「大きなメジャーバージョンアップ」であることが分かります（一部はGA後に追加されたものですが…）。特にmysqlxプラグイン関連のステータス変更からは、今後ドキュメントストア機能を一層推し進めていきたいという意思を感じます。

また、MySQLの急速な変化に「自前の監視ツールの対応（改修）が追いつかない－！」とお悩みの方は、Oracle公式の監視ツール
「MySQL Enterprise Monitor」（通称：MEM）の導入を検討されては如何でしょうか？（ライセンスの購入は以下の “お問合わせ” からどうぞ！）

※ ただしMEM8.0も本記事執筆時点で、完全にMySQL8.0の新機能・ステータス変数をカバーしているわけではございません