インラインTVFとビューのパフォーマンス

ビューの代わりにインラインTVF（テーブル値関数）を使用しているデータベースがあります。たとえば、TVF [fnCarBrands]内で結合している[車のモデル]と[車のメーカー]という2つのテーブルがあるとします。

これらのTVFは他のTVFから呼び出され、さらに処理とレポートを行います。したがって、関数[fnCarBrands]を受け取り、テーブル[購入年]に結合して、関数[fnCarBrandHistory]を作成します。TVFのいくつかの層についても同様です。

インラインTVFは実際にはテーブルと他のTVFの単なる結合なので、おそらくビューを使用して同じ機能を取得できます。

このように記述されたインラインTVFのパフォーマンスは、ビューとどのように比較されますか？

クエリオプティマイザーは、インラインテーブル値関数をビューのように扱います。

CREATE FUNCTION dbo.InlineUdf(@arg1 int)
RETURNS TABLE
AS
RETURN 
(
    ... your query here ...
);

複数ステートメントのテーブル値関数は、より多くのストアドプロシージャのように実行されます。これらは通常、メインのクエリに組み込まれるのではなく、複数回実行する必要があります。

CREATE FUNCTION dbo.MultiStatementUdf (@col1 int)
RETURNS @result TABLE 
(
    id int primary key NOT NULL,
    ... 
)
AS
BEGIN
   DECLARE @var1 int
   set @var1 = 42

   INSERT @result
   SELECT ...
   RETURN
END;

関数と同様のビューを作成し、実行プランを見てそれぞれにクエリを実行し、それぞれで何が起こっているかを確認する必要があります。

もちろん、他のビューを呼び出すビューを作成することも、パフォーマンスの向上につながります。そのルートを下らないでください。必要なクエリを記述し、パフォーマンスが必要な場合はTVFもビューも使用しないでください。これは、あるレイヤーあなたが頻繁に参照終わる特に以来、これはほとんど常にデータベースを照会したときに行うには悪いことであり、あなたはすぐにあなたも参照できるテーブルの数の制限に達してしまうことができ、問題を作成しています異なるレイヤーの同じテーブル。さらに、これは保守が容易であるように見えますが、そうではありません。修正する必要のあるレイヤーが最下部にある場合は、新しい要件のためにデバッグまたは列の追加を試してください。