Snowflakeキャッシュの仕組み｜Result Cache・Metadata Cache・Warehouse Cache

Snowflakeはクエリパフォーマンスの最適化のために3種類のキャッシュを自動的に管理しています。Result Cache（Cloud Servicesレイヤー）、Metadata Cache（Cloud Servicesレイヤー）、Warehouse Cache（コンピュートレイヤーのSSD）の動作レイヤーと無効化条件を正確に理解することは、パフォーマンスチューニングとSnowPro試験の両面で重要です。

3種類のキャッシュ比較表

Result Cache（Query Result Cache）

Result Cacheは、過去24時間以内に実行された同一SQLクエリの結果セットを保持し、同じクエリが再実行された際にウェアハウスを経由せず即座に結果を返す仕組みです。

クエリ実行フロー（Result Cache あり）:

[SQL: SELECT region, SUM(amount) FROM sales GROUP BY region]
       │
       ▼
[Cloud Services レイヤー]
       │
       ├─ Result Cache にヒット？
       │     │
       │     ├─ YES → キャッシュから即座に返却（WH不使用・クレジット消費なし）
       │     │
       │     └─ NO  → ウェアハウスでクエリ実行
       │                    │
       │                    └─ 結果を返却 + Result Cache に保存（24時間）
       ▼
[クエリ結果]

Result Cacheがヒットする条件

• SQL文が完全に一致する（大文字小文字・空白・コメントも含めて同一）
• 対象テーブルのデータが変更されていない
• 前回の実行から24時間以内
• 同一ロールで実行している（異なるロールではキャッシュ不適用）
• セッション変数 USE_CACHED_RESULT = TRUE（デフォルト）

Result Cacheが無効化される条件

-- Result Cacheを無効化してクエリ実行
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

SELECT region, SUM(amount) FROM sales GROUP BY region;
-- → 必ずウェアハウスで再実行される

-- Result Cacheを再有効化
ALTER SESSION SET USE_CACHED_RESULT = TRUE;

Metadata Cache

Metadata Cacheは、テーブルのメタデータ（行数、バイトサイズ、各マイクロパーティションのMIN/MAX値等）をCloud Servicesレイヤーに保持する仕組みです。メタデータだけで回答可能なクエリはウェアハウスを使わずに結果を返します。

-- Metadata Cacheで即座に回答されるクエリ例
SELECT COUNT(*) FROM large_table;      -- 行数はメタデータで保持
SELECT MIN(id) FROM large_table;       -- MIN/MAXはパーティションメタデータで保持
SELECT MAX(created_at) FROM large_table;

-- これらのクエリはウェアハウスが SUSPENDED でも実行可能
-- Query Profile で "METADATA-BASED RESULT" と表示される

Metadata Cacheが保持する情報

• テーブルの行数（ROW_COUNT）
• テーブルのバイトサイズ
• 各マイクロパーティションのMIN/MAX値（パーティションプルーニングに使用）
• 各マイクロパーティションのNULL数・DISTINCT値の概算
• テーブルのスキーマ定義

Warehouse Cache（Local Disk Cache）

Warehouse Cacheは、ウェアハウスのコンピュートノードに搭載されたSSD上にマイクロパーティションのローデータをキャッシュする仕組みです。リモートストレージ（S3/Azure Blob/GCS）からのI/Oを削減し、クエリの実行時間を短縮します。

クエリ実行フロー（Warehouse Cache あり）:

[SQL: SELECT * FROM sales WHERE region = 'APAC']
       │
       ▼
[ウェアハウスのコンピュートノード]
       │
       ├─ 必要なマイクロパーティションがSSD上にキャッシュされている？
       │     │
       │     ├─ YES → SSDからローカル読み込み（高速）
       │     │
       │     └─ NO  → リモートストレージ（S3等）から読み込み
       │                    │
       │                    └─ 読み込んだデータをSSDにキャッシュ
       ▼
[クエリ結果]

Warehouse Cacheの動作特性

クエリ実行時のキャッシュ評価順序

キャッシュ評価の優先順位:

[SQLクエリ受信]
       │
       ▼
[1] Metadata Cache チェック
       │  メタデータだけで回答可能？（COUNT(*), MIN, MAX等）
       │     ├─ YES → 即座に返却（WH不要）
       │     └─ NO  → 次のステップへ
       ▼
[2] Result Cache チェック
       │  同一SQL + 同一ロール + 24時間以内 + データ未変更？
       │     ├─ YES → キャッシュ結果を返却（WH不要）
       │     └─ NO  → 次のステップへ
       ▼
[3] ウェアハウスで実行（Warehouse Cache を活用）
       │  必要なマイクロパーティションがSSD上にあれば高速読み込み
       │  なければリモートストレージから読み込み + SSDにキャッシュ
       ▼
[クエリ結果返却 + Result Cache に保存]

AUTO_SUSPENDとキャッシュの関係

ウェアハウスのAUTO_SUSPEND設定はWarehouse Cacheの有効性に大きく影響します。

• AUTO_SUSPENDを短く設定（例: 60秒）→ 頻繁にサスペンドされWarehouse Cacheがクリアされる
• AUTO_SUSPENDを長く設定（例: 600秒）→ キャッシュが長く保持されるがアイドル時のクレジット消費が増加
• バッチ処理ではSUSPENDしてコスト削減を優先
• 対話的クエリではキャッシュ保持を優先しAUTO_SUSPENDを適度に長くする

Query Profileでのキャッシュ確認

-- Query Profileで確認できるキャッシュ関連指標

Result Cache ヒット時:
  → Query Profile に "QUERY RESULT REUSE" と表示
  → ウェアハウスの処理ノードが表示されない

Metadata Cache ヒット時:
  → Query Profile に "METADATA-BASED RESULT" と表示

Warehouse Cache 利用時:
  → Statistics タブで以下を確認
     - Percentage Scanned from Cache: SSDキャッシュからの読み込み割合
     - Bytes Scanned from Cache: キャッシュから読み込んだバイト数

-- Warehouse Cacheの効果を比較するクエリ
-- 1回目: リモートストレージから読み込み（Percentage Scanned from Cache = 0%）
-- 2回目: SSDキャッシュから読み込み（Percentage Scanned from Cache ≒ 100%）

試験対策のポイント

• Result Cacheは24時間保持、ウェアハウス不要で結果を返す
• Result Cacheは同一ロールでの実行が必要（異なるロールではキャッシュ不適用）
• Metadata Cacheは COUNT(*)/MIN/MAX 等のメタデータのみで回答可能なクエリに適用
• Warehouse CacheはSSD上のローデータキャッシュ、SUSPENDでクリア
• 非確定的関数（CURRENT_TIMESTAMP等）を含むクエリはResult Cache対象外
• テーブルデータの変更（DML）はResult Cacheを無効化する
• AUTO_SUSPENDの設定がWarehouse Cacheの有効性に影響する

サンプル問題

よくある質問