問題タブ [user-defined-functions]

これをユーザー定義関数として書きたいと思います：

これはUDFで行うことができますか?

状況は次のとおりです:
datetime パラメーターを持つテーブル値関数があります。たとえば、 tdf(p_date) とは言えません。これは、列の日付が p_date より小さい列を選択して約 200 万行をフィルター処理し、他の列の集計値を計算します。
それはうまく機能しますが、p_dateがカスタムスカラー値関数（私の場合は一日の終わりを返す）である場合、実行計画が変更され、クエリの実行時間が1秒から1分になります。

概念実証テーブル - 1,000 製品、2,000,000 行:

インライン テーブル値関数:

スカラー値関数:

クエリ 1 - うまくいっている

実行計画の終了: ストリーム集約コスト 13% <--- クラスタ化インデックス スキャン コスト 86%

クエリ 2 - あまり良くない

実行計画の終了: ストリーム集約コスト 4% <--- フィルター コスト 12% <--- クラスター化インデックス スキャン コスト 86%

"T-SQL: Opposite to string concatenation - how to split string into multiple records"dbo.Split()のようなテーブル値関数が与えられた場合、複数の行を引数として渡すにはどうすればよいですか?

これは機能します：

戻り値:

しかし、これはしません:

これもありません：

ドキュメントは言う：

テーブルを返すユーザー定義関数がサブクエリの FROM 句で呼び出される場合、関数の引数は外側のクエリの列を参照できません。

私が探している結果セットの種類は次のようになります。

これを達成する方法はありますか (もちろん、カーソルは別として)。

（編集）

MarlonRibunal のリクエストによると、上記の結果を生成するサンプル テーブルは次のようになります。

idですint。myColumnですvarchar(max)。

私のシステムはかなり重い処理を行っており、より短い時間でより多くのテストを実行できるようにするために、パフォーマンスを攻撃してきました。

たとえば、500 万行で UDF を呼び出さなければならないケースがかなりあります (そして、それを回避する方法はほとんどないと思っていました)。

結局のところ、これを回避する方法があり、行の合計セットよりもやや小さい個別のパラメーターのセットで UDF が呼び出されると、パフォーマンスが大幅に向上します。

一連の入力を受け取り、複雑なロジックに基づいて結果を返す UDF を考えてみましょう。ただし、500 万行を超える一連の入力の場合、たとえば 100,000 の個別の入力しかないため、100,000 の個別の結果タプルしか生成されません (私の特定のケースは金利から複雑なコード割り当てまでさまざまですが、それらはすべて離散的です。この手法の基本的なポイントは、を実行することでトリックが機能するかどうかを簡単に判断できることですSELECT DISTINCT)。

私はこのようなことをすることでそれを見つけました:

PreCalcs が適切にインデックス化されている場合、それと次の組み合わせ:

パフォーマンスが大幅に向上します。どうやら、何かが決定論的だからといって、SQL Server が過去の呼び出しをキャッシュして再利用しているとは限りません。

注意しなければならない唯一のことは、NULL が許可されている場所です。その後、結合を慎重に修正する必要があります。

これが役に立てば幸いです。UDF を使用した同様のトリックや、パフォーマンスのためのクエリのリファクタリングは大歓迎です。

問題は、なぜこのような手動キャッシュが必要なのかということだと思います-関数が決定論的であることをサーバーが知っているのはそれではないでしょうか? そして、それが非常に大きな違いを生み、UDF が非常に高価である場合、なぜオプティマイザーは実行計画でそれを行わないのでしょうか?

同じテーブルからいくつかの値を変換（ルックアップ）する必要がある場合があります。私が最初に書いた方法は、サブクエリを使用することでした。

私はこのサブクエリを頻繁に使用しているので（つまり、これらのフィールドを持つテーブルが約50あります）、サブクエリにさらにコードを追加する必要があるかもしれません（たとえば、「AND active = 1」）。 dこれらをユーザー定義関数UDFに入れて、それを使用します。しかし、そのUDFを使用したパフォーマンスはひどいものでした。

＃1のパフォーマンスは1秒未満です。＃2のパフォーマンスは約30秒です...

なぜ、またはもっと重要なことに、SQL Server 2008でコーディングできる方法があるので、それほど多くのサブクエリを使用する必要はありませんか？

編集：

これがいつ役立つかについてのもう少しの説明。この単純なクエリ（つまり、ユーザーIDの取得）は、ユーザーのテキストが必要な場合、言語を取得するためにプロファイルに参加し、言語をフェッチする必要があるかどうかを会社に確認する必要があるため、はるかに複雑になります。代わりにそこから編集し、翻訳されたテキストを取得するために翻訳テーブルを使用します。そして、これらのクエリのほとんどでは、パフォーマンスは読みやすさと保守性の二次的な問題です。

私が維持しているストアド プロシージャを最適化しようとしていますが、以下のオプションのパフォーマンスの利点/ペナルティについて誰かが私に手がかりを与えることができるかどうか疑問に思っています。私のソリューションでは、基本的に、テーブルの IMAGE 列に格納された画像に対して変換プログラムを実行する必要があります。変換プロセスは、外部の .EXE ファイルにあります。ここに私のオプションがあります：

1. ターゲット テーブルの結果を一時テーブルにプルし、カーソルを使用してテーブルの各行に移動し、IMAGE 列に対してストアド プロシージャを実行します。ストアド プロシージャは、.EXE を呼び出します。

2. .EXE ファイルを呼び出す UDF を作成し、「select UDFNAME(Image_Col) from TargetTable」のような SQL クエリを実行します。

私が探しているのは、カーソルをセットとして作成するのではなく、カーソルの作成によってどれだけのオーバーヘッドが追加されるかという考えだと思いますか?

いくつかの追加情報:

• この場合のセットのサイズは最大です。1000
• 以下の回答にあるように、UDFとセットで行うと、外部プログラムを一気に1000回開くということでしょうか？または、そのための最適化が行われていますか? 明らかに、マルチプロセッサ システムでは、プロセスの複数のインスタンスを実行することは悪いことではありませんが、1000 は少し多いかもしれません。

スカラー UDF のオプション "RETURNS NULL ON NULL INPUT" ( CREATE FUNCTIONを参照) は、パラメーターが null の場合、関数本体の実行を停止し、単に NULL を返します。

つまり、短絡します。

複数のパラメータを処理する方法を知っている人はいますか?

最初のパラメーターが少なくとも NULL の場合など、複数のパラメーターを使用して関数呼び出しを短絡すると便利です。

時間があれば、プロファイラーを使用して udf 呼び出しを追跡してみます。検索しましたが、何も見つかりません。おそらく、正しい検索用語を使用していない可能性があります。

それまでの間、誰かアイデアや経験をお持ちですか？

他の RDBMS ワールドからの回答も歓迎します。これは ANSI 設定であり、検索で DB2 と MySQL の結果が表示されました。

コメントに基づいて編集: 非 CLR 関数のみ

乾杯S

編集: プロファイラーを実行する必要はありません。どっ！これは動作を示しています。

私は次の機能を持っています：

しかし...

戻り値 (転置された結果):

IsDeterministic 0

正確 1

システム検証済み 1

システムデータアクセス 0

ユーザーデータアクセス 0

キャッシングの問題ではないことを確認するために、関数を数回削除して再作成しようとしました。CAST は、文字列 -> 整数に使用しているため、ここでは決定論的である必要があります。

私は完全に困惑しています、何かアイデアはありますか？

同僚が不可解なSQLクエリを持って私にやって来ました。

（本質的に）

ただし、返される結果セットには3つの数値がリストされます。

LEAST（id）
--------------
621
644
689

（すべて、LEAST関数がすべて一緒に欠けているかのようにクエリを満たすIDです）

なんで？=）