SQL Serverのスカラー関数とサブクエリの実行計画の分析

Question

次のクエリのSQL Server実行計画を理解できる人はいますか？

副問合せのバージョン（クエリ2）は、設定ベースであるため、より高速に実行することが期待されていました。これは、独立して、クエリを走ったときにケースのように表示されます - わずかに - 実行計画は、それぞれ15％対85％としてクエリのコストを示ししかし：

//-- Query 1 (15%) - Scalar Function 
SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    dbo.GetGalleryImageVotesByGalleryImageId(gi.GalleryImageId) AS Votes 
FROM 
    GalleryImage gi 

//-- Query 2 (85%) - Subquery 
SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    (SELECT COUNT(*) FROM GalleryImageVote WHERE GalleryImageId = gi.GalleryImageId) 
FROM 
    GalleryImage gi 

私はここで何をしないのです。実行計画は機能のコストをスキップしますか？また、上記のいずれかがCTEまたはOVER/PARTITIONクエリでうまく機能するかどうかについての提案はありますか？

ありがとうございます！

Answer 1

実行計画を信頼しないでください。 それはあなたが計画がどうなるか見てみましょうことは非常に便利ですが、あなたは本当のメトリックをしたい場合は、統計

set statistics io on 
set statistics time on 

..and実際の実行を比較する上常にターン。統計によれば、期待値は15％/ 85％と言われるかもしれませんが、実際には実際に何が変換されるのかが示されます。

パフォーマンスチューニングのための銀色の弾丸はありません。データの形や分布が変化すると、「最良の」クエリでも時間の経過と共に変化する可能性があります。

CTEの違いはあまりありませんが、これ以上PARTITIONクエリをどのように計画するのかはわかりませんが、left joinフォームを試すことができます。

SELECT 
    gi.GalleryImageId, 
    gi.FbUserId, 
    count(v.GalleryImageId) AS Votes 
FROM 
    GalleryImage gi 
    LEFT JOIN GalleryImageVote v ON v.GalleryImageId = gi.GalleryImageId 
GROUP BY 
    gi.GalleryImageId, gi.FbUserId 

Answer 2

オプティマイザは機能のコストを知りません。

あなたは同様の質問からいくつかの関連解答

かかわらプロファイラを介してCPUと読み込み、持続時間を見ることができます。 OneTwo

• インライン表関数は、メイン・クエリ（彼らが望むようなマクロです）
• スカラー（あなたの1）に拡大し、マルチステートメントの表関数は、「外側」のクエリ
にないし、ブラックボックスです