いくつかのストアド プロシージャで必要なかなり大きなクエリがあり、それを UDF に移行して保守を容易にしたいと考えています (ビューは機能しません。これは多数のパラメーターを取り込みます)。 UDF は信じられないほど遅いと話したことがあります。
正確な原因はわかりませんが、そうであると推測しますが、このUDFを結合内で使用しているのではなく、代わりにテーブル変数を返すため、そうではないと思いますそんなに悪いこと。
質問は、UDF を絶対に避けるべきかということだと思います。彼らが遅いという具体的な証拠を指摘できる人はいますか?
スカラーUDFは非常に低速であり、インラインUDFは実際にはマクロであるため、非常に高速です。いくつかの記事：
スカラーUDFの速度に関するその他のリンク：
（テーブル）udfの結果は何にも結合されないことを指摘したように、パフォーマンスに影響はありません。
UDF が遅いと認識される理由 (実際には間違った方法で使用されているだけ) について少し説明するために、次の例を考えてみましょう。
テーブル A とテーブル B があります。
A.col1、A.col2、B.ColWhatever を選択 A から B を結合 A.aid = b.fk_aid WHERE B.someCol = @param1 AND A.anotherCol = @param2
この場合、SQL Server は、認識している最もパフォーマンスの高い方法で結果を返すよう最善を尽くします。これの主な要因は、ディスクの読み取りを減らすことです。そのため、JOIN 句と where 句の条件を使用して (できればインデックスを使用して) 返される行数を評価します。
ここで、UDF に返されるデータの量を制限するために使用される条件の一部を抽出するとします。現在 - クエリ オプティマイザは、ディスクから最小量の行を引き戻すことができなくなり、提供された条件のみを処理できます。簡単に言えば、テーブル udf は常に評価され、メイン sproc に返される前にデータが返されるため、元の結合に他の条件があり、ディスクの読み取りが少なくなる可能性がある場合、これはデータにのみ適用されます。 sproc に引き込まれた後。
そこで、where 句に一致するテーブル B から行を選択する UDF を作成するとします。テーブル B に 10 万行があり、そのうちの 50% が where 句の条件を満たしている場合、これらの行はすべて sproc に返され、テーブル A と比較されます。これらの行の 10% のみがテーブル A に一致する場合作業したいテーブル B の 5% しか話していませんが、既に 50% を引き戻しており、その大部分は不要です!
これが完全な意味不明な謝罪と思われる場合は、お知らせください。
コードを投稿できますか？一般的に言えば、クエリの select 句でスカラー udf を使用している場合、udf 内のステートメントは、クエリから返される行ごとに 1 回実行されます。テーブル値 udf への結合を実行するか、メインの SQL ステートメントで結合を使用して、udf 内でロジックを実行する方法を見つけたほうがよいでしょう。
UDFの代わりにストアドプロシージャを使用したくない理由はありますか？