Fabric Data Engineer Associate（DP-700） 無料問題 8 / 10 ・ 分野3: 分析ソリューションの監視と最適化
Fabric の Warehouse WH_Sales（結果セットのキャッシュは既定のまま）で、レポートが同じ SELECT を1時間ごとに実行している。この SELECT は、WH_Sales の 500 万行のファクト テーブルと 5,000 行の店舗テーブルを結合し、さらに同じワークスペースの別の Warehouse WH_Master の商品テーブルを3部構成の名前で結合して、約 200 行に集計し、出力に含む列で ORDER BY している。実行のあとのメッセージに「Result set cache was used」が一度も出ない。結果セットのキャッシュのページの説明から、キャッシュの対象にならない理由として合うものはどれか。
- 結果が約 200 行と少なく、キャッシュするほどの重い処理と見なされないため
- ORDER BY を含むクエリは、並べ替えの結果が実行のたびに変わりうるため
- 店舗テーブルが 5,000 行で、どのテーブルも 10 万行以上という条件を満たさないため
- 接続している Warehouse に含まれない WH_Master のテーブルを参照しているため
正解と解説を見る
正解: D
正解の理由
ページは結果セットのキャッシュの対象にならないよくある理由として、接続している Fabric の項目の外にあるオブジェクトを参照するクエリ（データベースをまたぐクエリなど）を挙げる。WH_Master の商品テーブルを3部構成の名前で結合しているので、この SELECT はキャッシュの作成にも利用にも当たらず、毎回元のクエリをすべて処理する。ページはキャッシュを使えない場面としても、元のクエリと別の Lakehouse や Warehouse の接続から呼ばれたときを挙げ、データベースをまたぐクエリはキャッシュの対象外だと重ねて書いている。
違う選択肢
「結果が約 200 行と少なく、キャッシュするほどの重い処理と見なされないため」… ページが対象外に挙げるのは、結果が 10,000 行を超えると見込まれるクエリで、少ない結果は対象から外れない。ページはむしろ、大量のデータを処理して小さな結果を出す分析のクエリを、キャッシュが効く典型として挙げている。
「店舗テーブルが 5,000 行で、どのテーブルも 10 万行以上という条件を満たさないため」… ページの条件は、少なくとも1つのテーブルが 10 万行以上あることで、全部のテーブルではない。500 万行のファクト テーブルがあるので、この条件は満たしている。
「ORDER BY を含むクエリは、並べ替えの結果が実行のたびに変わりうるため」… ページが対象外に挙げるのは、出力に含まれない列や式で ORDER BY するクエリで、ORDER BY そのものではない。設問の ORDER BY は出力に含む列なので、この条件には当たらない。
押さえどころ
結果セットのキャッシュは、Warehouse と Lakehouse の SQL 分析エンドポイントで既定で有効になっており、項目ごとに ALTER DATABASE … SET RESULT_SET_CACHING OFF で止められる。1つのクエリだけ止めるときは、SELECT の末尾に OPTION ( USE HINT ('DISABLE_RESULT_SET_CACHE') ) を付ける。参照するテーブルが変わるとキャッシュは無効になり、24時間使われないキャッシュも使われなくなる。