目次 › 第4章 › 4-1

第4章 パフォーマンス最適化・クエリ・変換 / 想定学習時間:30〜40分 / 最終確認:2026年8月

4-1. Query Profileの読み方とボトルネック診断

1. Query Profileとは:クエリ実行の「レントゲン写真」

クエリが遅いとき、当てずっぽうでウェアハウスを大きくするのは正しいアプローチではありません。Snowflake には、実行済み(または実行中)のクエリが内部でどのように処理されたかを可視化する Query Profile(クエリプロファイル)があります。Snowsight の Monitoring › Query History(クエリ履歴)から対象クエリを選び、「Query Profile」タブを開くと確認できます。

Query Profile には主に次の情報が表示されます。

2. 見るべきシグナル①:Partitions scanned vs total(プルーニング効率)

統計欄の Partitions scanned(スキャンしたパーティション数)と Partitions total(テーブルの総パーティション数)の比率は、1-6 で学んだパーティションプルーニングがどれだけ効いているかを直接示します。

• scanned が total よりずっと小さい:プルーニングが効いており、必要な部分だけを読めています。
• scanned ≒ total:フィルタ条件があるのにほぼ全パーティションを読んでいる状態です。フィルタ列とデータの物理的な並び(クラスタリング)が合っていない可能性があり、クラスタリングキーの検討や、フィルタ列に関数を適用しない書き方への修正などが対策候補になります。

-- 効きにくい:フィルタ列を関数で加工すると、min/max メタデータで絞り込めない
SELECT * FROM sales
WHERE TO_CHAR(order_date, 'YYYY-MM') = '2026-08';

-- 効きやすい:列はそのまま、範囲条件で書く
SELECT * FROM sales
WHERE order_date >= '2026-08-01' AND order_date < '2026-09-01';

3. 見るべきシグナル②:スピル(Spillage to local / remote storage)

ソートや大きな集計・結合の途中結果がウェアハウスのメモリに収まらないと、Snowflake はデータを一時的にディスクへ書き出します。これをスピル(spilling)と呼び、統計欄に次の2段階で表示されます。

スピルの根本原因は「処理データ量に対してメモリが不足している」ことなので、対策の基本はウェアハウスサイズを1段階上げる(スケールアップ)ことです。サイズを上げるとノード数とともに総メモリ量が増えるため、スピルが解消してかえって実行時間が短くなり、課金時間の増加を相殺できる場合もあります。あわせて、不要な列を SELECT しない、早い段階で行を絞り込むといったクエリ自体の見直しも有効です。

4. 見るべきシグナル③:Exploding join(結合の爆発)

Join ノードの出力行数が入力行数より大幅に多い場合、結合条件の不足や誤りにより行が掛け算的に膨らんでいる可能性があります。これは Exploding join と呼ばれる典型的なアンチパターンで、結合条件を書き忘れたデカルト積(Cartesian product)が極端な例です。

-- 結合条件が欠けており、行数が m × n に爆発する
SELECT *
FROM orders o
JOIN customers c;  -- ON 句がない!

-- 正しい結合条件を指定する
SELECT *
FROM orders o
JOIN customers c
  ON o.customer_id = c.customer_id;

Query Profile では、Join ノードの入力行数と出力行数を見比べることで発見できます。対策はウェアハウスの増強ではなく、結合条件(結合キー)の見直しです。重複キーによる意図しない多対多結合も同じ症状を引き起こします。

5. 見るべきシグナル④:キュー待ち(Queued time)とTableScan支配

クエリ履歴やプロファイル概要で Queued(キュー待ち)時間が長い場合、クエリ自体は悪くなく、ウェアハウスが過負荷で実行開始を待たされています。同時実行数が多すぎるのが原因なので、対策はサイズアップではなくマルチクラスタウェアハウスによるスケールアウトや、ワークロードを別ウェアハウスに分離することです(詳細は 4-3)。

また、演算子ツリーで TableScan が実行時間の大半を占める場合は、読み取りデータ量そのものが支配的です。フィルタ条件の追加・SELECT する列の削減・クラスタリングの改善など、スキャン量を減らす対策を検討します。

6. 症状→診断→対策の対応表とフロー

ここまでのシグナルを「症状から対策を引く」形に整理します。この対応付けは実務でもそのまま使えます。

7. QUERY_HISTORYとクエリタグによる調査

個別クエリの深掘りは Query Profile が担当しますが、「昨日遅かったクエリを一覧したい」「アプリ別に実行状況を集計したい」といった横断調査には QUERY_HISTORY を使います。同名で2系統ある点に注意してください。

-- セッションにクエリタグを設定しておく(アプリ名やバッチ名など)
ALTER SESSION SET QUERY_TAG = 'nightly_etl';

-- タグを手がかりに、実行時間の長い順に調査する
SELECT query_id, query_text, total_elapsed_time, warehouse_name
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE query_tag = 'nightly_etl'
ORDER BY total_elapsed_time DESC
LIMIT 10;

練習問題