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

4-2. 3つのキャッシュ(結果キャッシュ・ウェアハウスキャッシュ・メタデータキャッシュ)

🎯 この節の学習目標

クエリ結果キャッシュの保存場所・寿命(24時間、最大31日)・再利用の条件を説明できる
ウェアハウスキャッシュ(ローカルディスクキャッシュ)がサスペンドで消えることと、auto-suspend 設定とのトレードオフを説明できる
メタデータキャッシュにより、ウェアハウスなしで応答できるクエリの例を挙げられる
3つのキャッシュを「どの層・寿命・効く条件」で比較・区別できる

1. なぜ3つのキャッシュを区別するのか

Snowflake には性質の異なる3種類のキャッシュがあり、それぞれ存在する層(クラウドサービス層か、ウェアハウスか)と寿命、効く条件が違います。この3つを混同すると、「ウェアハウスを止めたのに結果が即座に返るのはなぜか」「同じクエリなのにキャッシュが効かないのはなぜか」といった動作が説明できません。試験でも3つを区別させる問題が中心なので、本節は比較表まで含めて確実に押さえてください。

2. クエリ結果キャッシュ(Query Result Cache)

クエリ結果キャッシュは、実行したクエリの結果そのものをクラウドサービス層に保存する仕組みです。条件を満たす同一クエリが再度実行されると、Snowflake は計算をやり直さず、保存済みの結果をそのまま返します。

保存場所:クラウドサービス層(特定のウェアハウスに属さない)。そのため、別のウェアハウスや別のユーザーからのクエリでも再利用できます(データへの十分なアクセス権限があることが前提です)。
寿命:結果は 24時間保持されます。ただし再利用されるたびに保持期間がリセットされ、最大31日まで延長されます。31日を超えるか、元データが変更されると無効になります。
ウェアハウス不要:キャッシュヒット時は計算が発生しないため、ウェアハウスが起動していなくても(サスペンド中でも)結果が返り、ウェアハウスのクレジットを消費しません。

再利用には、主に次の条件をすべて満たす必要があります。

条件	補足
クエリテキストが実質的に同一	空白や大文字小文字の違いでも別クエリと見なされることがある。構文的に同じ結果を返すだけでは不十分
対象テーブルのデータが変わっていない	INSERT/UPDATE/DELETE などでデータやマイクロパーティションが変化すると無効化される
実行時依存の関数を含まない	CURRENT_TIMESTAMP() や RANDOM() など、実行のたびに値が変わる関数を含むと再利用されない
十分な権限がある	結果を再利用するユーザーが、対象テーブルへの必要な権限を持っていること
USE_CACHED_RESULT が TRUE	既定は TRUE。FALSE にすると結果キャッシュを使わない

💡 具体例:性能検証のためにキャッシュを無効化する

-- セッション単位で結果キャッシュを無効化(チューニングの計測時に使う)
ALTER SESSION SET USE_CACHED_RESULT = FALSE;

-- 1回目:ウェアハウスで実行される
SELECT region, SUM(amount) FROM sales GROUP BY region;

-- 2回目:USE_CACHED_RESULT=TRUE なら結果キャッシュから即座に返るが、
-- FALSE にしているため毎回ウェアハウスで実行される

ウェアハウスサイズ変更などの効果を測るときは、結果キャッシュが効くと計測になりません。USE_CACHED_RESULT = FALSE で無効化してから比較するのが定石です。

3. ウェアハウスキャッシュ(ローカルディスクキャッシュ)

ウェアハウスキャッシュは、仮想ウェアハウスの各ノードが、クエリ実行時にリモートストレージから読み取ったテーブルデータ(マイクロパーティション)を自身のローカルディスク(SSD)に保持しておく仕組みです。データキャッシュ、ローカルディスクキャッシュとも呼ばれます。

保存場所:各ウェアハウスのノード内。したがってそのウェアハウスで実行するクエリだけに効きます(他のウェアハウスとは共有されません)。
寿命:ウェアハウスが稼働している間だけ有効です。サスペンドするとキャッシュは消え、再開後は再びリモートストレージから読み直しになります。
効き方:結果キャッシュと違い、クエリが同一である必要はありません。同じテーブルデータの一部を読む別のクエリでも、キャッシュ済みの部分はリモート読み取りを省略でき、その分速くなります。

📝 試験のポイント

auto-suspend の設定とのトレードオフが問われます。サスペンドまでの時間を短くするほどアイドル時のクレジット消費は抑えられますが、サスペンドのたびにウェアハウスキャッシュが失われ、再開直後のクエリが遅くなります。断続的にクエリが来る BI 用ウェアハウスなどでは、auto-suspend を極端に短くするとかえって体感性能とコスト効率が悪化することがあります。「コスト節約」と「キャッシュ維持」のバランスとして理解しておきましょう。

4. メタデータキャッシュ

Snowflake はクラウドサービス層で、各テーブル・各マイクロパーティションの統計情報(行数、列ごとの最小値・最大値、個別値数など)を常に保持しています。このメタデータだけで答えられるクエリは、ウェアハウスを使わずに応答されることがあります。

-- メタデータだけで応答できることがあるクエリの例
SELECT COUNT(*) FROM sales;          -- 行数はメタデータに記録済み
SELECT MIN(order_date), MAX(order_date) FROM sales;  -- min/max も記録済み

-- SHOW / DESCRIBE などのメタデータ操作もウェアハウス不要
SHOW TABLES IN SCHEMA analytics.public;

これらはウェアハウスがサスペンド中でも即座に返り、ウェアハウスのクレジットを消費しません。なお、WHERE 句で複雑に絞り込んだ COUNT や、一般の SELECT はメタデータだけでは答えられないため、通常どおりウェアハウスで実行されます。メタデータは 1-6 で学んだパーティションプルーニングにも使われており、「クラウドサービス層が持つ統計」という同じ仕組みの別の顔です。

5. 3つのキャッシュの比較表とクエリ処理の流れ

3つのキャッシュを1枚の表に整理します。この表の内容はそのまま試験の論点です。

	クエリ結果キャッシュ	ウェアハウスキャッシュ	メタデータキャッシュ
どの層にあるか	クラウドサービス層	各ウェアハウスのローカルディスク	クラウドサービス層
何を保持するか	クエリの結果	読み取ったテーブルデータ	統計情報(行数・min/max など)
寿命	24時間(再利用で延長、最大31日)。データ変更で無効化	ウェアハウス稼働中のみ。サスペンドで消える	常に最新に維持される(明示的な期限なし)
効く条件	同一クエリテキスト+データ不変+権限などの条件を満たす再実行	同じウェアハウスで、同じデータ(の一部)を読むクエリ	COUNT(*)・MIN/MAX など統計だけで答えられるクエリ
ウェアハウス	不要(クレジット消費なし)	必要(稼働中のWHで効く)	不要(クレジット消費なし)
共有範囲	ウェアハウス・ユーザーをまたいで再利用可(権限が必要)	そのウェアハウス内のみ	アカウント全体

クエリが発行されたとき、Snowflake が概念的にどの順で応答手段を選ぶかをフローで示します。

クエリ発行ユーザー/アプリが SQL を実行

↓クラウドサービス層で解析・最適化

結果キャッシュにヒットするか?同一クエリ・データ不変・権限などの条件を確認

ヒット:結果を即返却ウェアハウス不要・クレジット消費なし

↓ヒットしない場合

メタデータだけで応答できるか?COUNT(*) や MIN/MAX などの統計クエリ

応答可能:メタデータから即返却ウェアハウス不要

↓どちらも不可の場合

ウェアハウスで実行ローカルディスクキャッシュにあるデータは再利用し、足りない分だけリモートストレージから読む

図:クエリ応答の概念フロー。上の2段はウェアハウスを起動せずに完結する

✅ この節のまとめ

クエリ結果キャッシュ:クラウドサービス層に結果を保持。24時間(再利用で延長、最大31日)。同一クエリテキスト・データ不変・十分な権限などが条件で、ウェアハウス不要。USE_CACHED_RESULT = FALSE で無効化できる。
ウェアハウスキャッシュ(ローカルディスクキャッシュ):ウェアハウス稼働中のみ有効で、サスペンドすると消える。auto-suspend を短くしすぎるとキャッシュ喪失で再開後が遅くなるトレードオフがある。
メタデータキャッシュ:クラウドサービス層の統計により、COUNT(*) や MIN/MAX などはウェアハウスなしで応答されることがある。
比較の軸は「どの層か・何を保持するか・寿命・効く条件・ウェアハウスの要否」。この5点で3つを言い分けられれば十分。

練習問題

問1. クエリ結果キャッシュに関する説明として正しいものはどれか。

結果は各ウェアハウスのローカルディスクに保存されるため、同じウェアハウスからのクエリでのみ再利用できる
結果はクラウドサービス層に保存され、条件を満たせばウェアハウスを起動せずに結果が返る
ウェアハウスをサスペンドすると結果キャッシュも同時に消える
結果キャッシュは一度保存されると31日間、データが変更されても使い続けられる

解答と解説を見る

正解:B

結果キャッシュはクラウドサービス層にあり、ヒット時は計算不要なのでウェアハウスなし・クレジット消費なしで返ります。Aはウェアハウスキャッシュの説明です。Cは誤りで、結果キャッシュはウェアハウスに属さないため、サスペンドの影響を受けません。Dは誤りで、元データが変更されるとキャッシュは無効化されます(31日は「再利用され続けた場合の最大延長」です)。

問2. ウェアハウスの auto-suspend を60秒などごく短く設定した場合に起こり得ることとして、最も適切なものはどれか。

クエリ結果キャッシュが失われ、すべてのクエリが再計算になる
メタデータキャッシュが失われ、COUNT(*) が遅くなる
サスペンドのたびにローカルディスクキャッシュが失われ、再開直後のクエリでリモートストレージからの読み直しが増える
キャッシュには影響がなく、コストだけが必ず削減される

解答と解説を見る

正解:C

ローカルディスクキャッシュはウェアハウス稼働中のみ有効なので、頻繁なサスペンドはキャッシュの喪失を繰り返し、再開後の初回クエリ群が遅くなります。A・Bのキャッシュはどちらもクラウドサービス層にあり、ウェアハウスのサスペンドの影響を受けません。Dは誤りで、アイドル課金は減るものの、キャッシュ喪失による性能低下(および実行時間の延び)という代償があり、「必ず得」とは言えません。

問3. ウェアハウスがすべてサスペンドされている状態で、即座に結果が返る可能性のあるクエリはどれか。2つ選べ。

SELECT COUNT(*) FROM sales;
SELECT * FROM sales WHERE amount > 100;(初めて実行するクエリ)
10分前に別ユーザーが実行したものと同一テキストの集計クエリ(データ変更なし・権限あり)
SELECT CURRENT_TIMESTAMP(), region, SUM(amount) FROM sales GROUP BY region;(直前に同一クエリを実行済み)

解答と解説を見る

正解:A、C

Aは行数というメタデータだけで応答できる可能性があり、ウェアハウス不要です。Cは結果キャッシュの再利用条件(同一テキスト・データ不変・権限)を満たしており、クラウドサービス層から返せます。Bは実データのスキャンが必要な初回実行なのでウェアハウスの起動(レジューム)が必要です。Dは CURRENT_TIMESTAMP() という実行のたびに値が変わる関数を含むため、結果キャッシュが再利用されません。

問4. ウェアハウスサイズ変更の性能効果を正しく計測するために、事前に行うべき設定はどれか。

ALTER SESSION SET USE_CACHED_RESULT = FALSE を実行する
ALTER SESSION SET QUERY_TAG = 'benchmark' を実行する
ウェアハウスの auto-resume を無効にする
メタデータキャッシュを DROP CACHE 文で削除する

解答と解説を見る

正解:A

結果キャッシュが効くと2回目以降の実行は計算そのものをスキップしてしまい、ウェアハウス性能の比較になりません。USE_CACHED_RESULT = FALSE で結果キャッシュを無効化してから計測します。Bのクエリタグは調査用のラベル付けであり、キャッシュ動作には影響しません。Cはレジュームの自動化設定で計測とは無関係です。Dのような「メタデータキャッシュを削除する」構文は存在しません。