本文へスキップ

MySQL SQL統計

情報

MYSQL SQL統計は今後SQL統計（DB）に名称が変更される予定です。

MySQLのperformance_schema.events_statements_summary_by_digestビューで提供するDB自体のSQL統計です。SQL別の実行回数、実行時間、処理Row数などのデルタ値をDBに直接照会することなく画面で確認できます。

  • エージェントが1時間間隔でデルタ値を計算して収集します。

  • sum_timer_wait基準でエージェントオプションstatements_row_limitまで収集します。（デフォルト値：5,000件）

  • DBXエージェント1.6.10バージョン以上が必要です。

ノート

設定完了後、約1時間後にデータ収集が開始されます。

事前設定​

この画面にデータを表示するには、DB設定とエージェント設定の2つが必要です。

DB設定​

  1. Performance Schemaの有効化（my.cnf）

    変更後、MySQLの再起動が必要です。

    [mysqld]
    performance_schema = on

  2. モニタリングアカウントへの権限付与

    エージェントがperformance_schemaを照会できるようにDBで権限を付与します。

    GRANT SELECT ON performance_schema.* TO 'whatap'@'%';

エージェント設定​

whatap.confファイルに以下の設定を追加します。

statements=true
設定項目タイプデフォルト値説明
statementsbooleanfalseSQL統計収集の有効化
詳細オプション
設定項目タイプデフォルト値説明
statements_intervalint1SQL統計収集間隔（時間単位）
statements_min_rowint10000SQL統計データを収集する基準。下記の収集基準を参照してください。
statements_row_limitint5000収集最大件数（sum_timer_wait基準の上位）

収集基準（statements_min_row）

performance_schema.events_statements_summary_by_digestの以下の3つの指標のいずれか1つでもstatements_min_rowを超える（OR）場合に、該当SQLデータを収集します。

指標説明
sum_rows_affected影響を受けた行数
sum_rows_sent送信された行数
sum_rows_examined検査した行数
ノート

DBワークロードによってSQL収集量が多すぎるまたは少なすぎる場合、statements_min_rowとstatements_row_limitの値を調整して収集量を制御できます。

MYSQL SQL統計​

基本オプション​

上部フィルター領域で照会期間、対象インスタンス、フィルター条件などを設定できます。

  • 時間: 照会する日時を選択

  • インスタンス: 照会対象DBインスタンスを選択

  • フィルター: 条件別データフィルタリング（複数条件はANDロジックを適用）

  • ソート順: カラムヘッダーをクリックして昇順/降順ソート

  • 照会件数: テーブル表示件数を設定

  • 結果内検索: 照会された結果内でクエリキーワード検索

  • カラムアイコン（カラム選択）: 表示するカラムを追加/削除、ドラッグで順序変更可能

  • ダウンロードアイコン（ダウンロード）: CSV形式でエクスポート

カラムガイド​

基本情報​

カラム説明
digest_text正規化されたSQL文（リテラル値が?に置換される）
digestSQL文のハッシュ値
schema_nameSQLが実行されたスキーマ（データベース）名
instanceSQLが実行されたDBインスタンス名

実行および時間​

カラム説明
count_starSQL実行回数
timer_wait全実行時間合計（秒）
lock_timeテーブルロック待ち時間合計（秒）

Row処理​

カラム説明
rows_affectedINSERT、UPDATE、DELETEで変更されたRow数
rows_sentクライアントに返されたRow数
rows_examinedサーバーが検討したRow数（ストレージエンジン内部処理を除く）

一時テーブル​

カラム説明
created_tmp_disk_tablesディスクに作成された内部一時テーブル数
created_tmp_tablesメモリに作成された内部一時テーブル数

ジョイン（Select）​

カラム説明
select_full_joinジョイン時にインデックスなしでFull Table Scanした回数
select_full_range_joinジョイン時にRangeスキャンを使用した回数
select_range最初のテーブルでインデックスRangeスキャンを使用した回数
select_range_check各Rowごとにインデックス使用可否を再確認したジョイン回数
select_scan最初のテーブルをFull Scanした回数

ソート（Sort）​

カラム説明
sort_merge_passesSortバッファ不足により一時ファイルにマージソートした回数
sort_rangeRangeスキャンを利用したソート回数
sort_rowsソートされた全Row数
sort_scanFull Scanを利用したソート回数

インデックス使用​

カラム説明
no_index_usedインデックスを使用せずにテーブルスキャンした回数
no_good_index_used適切なインデックスなしに実行された回数

データ解釈ガイド​

チューニング対象SQLの識別​

  • timer_waitが高くcount_starも高いSQL: 頻繁に実行されながら遅い → 最優先チューニング対象

  • rows_examined / rows_sentの比率が大きいSQL: 不必要なRowを多くスキャン → インデックス確認

  • lock_timeが高いSQL: ロック競合が発生 → 同時実行性の問題を確認

インデックス確認が必要な場合​

  • select_full_join > 0: ジョイン用インデックスの追加を検討

  • select_range_check > 0: ジョイン条件とインデックス構成の確認

  • no_index_used > 0: インデックスの作成が必要

  • no_good_index_used > 0: 既存インデックスが適切でない

メモリ/ディスク効率の確認​

  • created_tmp_disk_tablesが高い場合、tmp_table_size、max_heap_table_sizeの増設を検討

  • sort_merge_passesが高い場合、sort_buffer_sizeの増設を検討

  • created_tmp_disk_tables / created_tmp_tablesの比率でディスク転換率を確認

実践活用シナリオ​

シナリオ1. 遅いSQLを探す​

  1. timer_wait基準で降順ソート

  2. 上位SQLのcount_starを確認 → 頻繁に実行されながら遅いSQLが最優先チューニング対象

シナリオ2. 非効率なSQLを探す​

  1. rows_examinedが高いのにrows_sentが低いSQLを確認

  2. インデックスがないか適切でなく、不必要なRowを多くスキャン中

  3. 該当SQLのPlan（実行計画）を確認してインデックス追加の有無を決定

シナリオ3. ロック競合の確認​

  1. lock_timeが高いSQLを確認

  2. そのテーブルへの同時アクセスが多いか、トランザクションが長時間維持されている可能性あり

追加機能​

SQL詳細表示​

SQLカラムをクリックすると詳細情報ウィンドウが開きます。SQL詳細ウィンドウの説明は以下を参照してください。

DB参考情報​

events_statements_summary_by_digest​

画面のデータはDBのevents_statements_summary_by_digestビューから取得するため、DB設定変更やデータ削除が収集データに直接影響します。

performance_schema_digests_size​

performance_schema_digests_sizeパラメータは、異なるSQLパターン（digest）を最大何個まで保存するかを決定します。-1の場合、自動サイズ調整（auto sizing）が実行されます。

-- 例：以下の2つのSQLは同じdigestに正規化されます。
SELECT * FROM user WHERE id = 10;
SELECT * FROM user WHERE id = 20;
→ SELECT * FROM user WHERE id = ?

digest数がlimitを超えると、新しいSQLパターンは個別の統計として集計されず、DIGEST = NULLのRowに合算されます。この場合、どのSQLか識別できず、モニタリングで一部のSQLが欠落する可能性があります。

-- 現在のlimitを確認
SHOW VARIABLES LIKE 'performance_schema_digests_size';

-- digestの使用量を確認
SELECT COUNT(*) FROM performance_schema.events_statements_summary_by_digest;

-- overflowの有無を確認（NULL digestに統計が蓄積されている場合はlimit超過）
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST IS NULL;
TRUNCATE初期化​

TRUNCATEコマンドでビューを初期化すると、既存データがすべて削除され、新しいデータが記録されます。エージェントが収集するデルタ値も初期化されるため注意してください。

最終修正：