クエリ1：プルーニングが「使える」理由
WHERE C_CUSTOMER_SK between 100000 and 600000
AND C_LAST_NAME LIKE 'Johnson'理由：データの「並び順」と「メタデータ」の相性が良い
- ID（SK）の連続性:
C_CUSTOMER_SK（サロゲートキー）のような連番のIDは、通常、データがロードされた順序と一致します。Snowflakeはデータをロード順にマイクロパーティションに分割するため、各パーティションのC_CUSTOMER_SKの「最小値〜最大値」の範囲が非常に狭く、重複しにくくなります。 - 劇的な絞り込み: 「10万から60万の間」という条件があれば、Snowflakeのメタデータを見るだけで、「このファイルは1〜5万だから無視」「このファイルは10〜15万だから読む」と、読むべきファイルを物理的に切り捨て（プルーニング）できます。
クエリ2：プルーニングが「効きにくい」理由
WHERE C_LAST_NAME = 'Johnson'理由：データの「散らばり」が大きすぎる
- 名前のランダム性: データのロード順が「名前順」になっていない限り、
C_LAST_NAME（姓）はあらゆるマイクロパーティションに分散して保存されます。 - メタデータの限界: 全てのパーティションのメタデータ（最小値〜最大値）が「Aさん〜Zさん」という広い範囲をカバーしてしまっている場合、Snowflakeは「’Johnson’ さんがどのファイルにいるか分からない（＝全ファイルにいる可能性がある）」と判断します。
- 結果: 結局、ほぼ全てのパーティションをスキャンしなければならなくなり、パフォーマンスが低下します。
3. なぜ「LIKE」と「=」の違いではないのか？
ここで重要なのは、演算子が LIKE か = かではなく、「フィルタリングするカラムが、データの物理的な並び順（クラスタリング）を反映しているか」です。
| 比較項目 | クエリ1 (C_CUSTOMER_SK) | クエリ2 (C_LAST_NAME) |
| 主なフィルタ | 数値の範囲指定（連番） | 文字列の完全一致（ランダム） |
| データの偏り | 特定のファイルに固まっている | 全ファイルに散らばっている |
| プルーニング | 非常に効きやすい | 効きにくい（全スキャンに近い） |
| 処理速度 | 速い（読まないファイルが多い） | 遅い（ほぼ全部読む） |
クエリ1（成功）: 「本のIDが100番〜200番の本を持ってきて」
クエリ2（失敗）: 「著者が『佐藤さん』の本を全部持ってきて」