2

関数があり、99、4、3 などの整数を渡します。

関数は別の整数を返します（効果的に変換します）

今、この関数が選択で呼び出されることがわかったので、関連するすべてのテーブルを含む 300 行のインポートの場合、数値変換関数が呼び出される合計回数は 250k 回です!

これは私をとても怖がらせます-私の質問は、クエリに結合されたルックアップテーブルでこれがより良いかどうかです-したがって、選択から関数を削除します。

4

3 に答える 3

3

作成された場合、テーブルのインデックスを利用できるため、ルックアップテーブルに投票しますまた、テーブルに対して実行する場合、各行に対して関数を実行する必要はありません

しかし、ルックアップ テーブルの問題の 1 つは、可能なすべての入力を処理する必要があることです。ルックアップテーブルで対応できるケースは限られています。

したがって、考えられるすべての入力に対してルックアップ テーブルを作成できる場合、ルックアップ テーブルは関数よりもパフォーマンスが優れています。

于 2012-08-03T08:55:27.620 に答える
2

関数のロジックを select ステートメントにコピーできますか?

例えば

SELECT (a.ValueA + a.ValueB) as [ValueC]
FROM SomeTable a
于 2012-08-03T09:22:29.447 に答える
2

最初のアプローチでは、(関連する関数の) クエリ/ロジックを select 句自体に記述することをお勧めします。パフォーマンスの向上が見られることは間違いありません。私も 7,000,000 レコードのパフォーマンスの問題を抱えていました。これは私を少し助けました。いいえ。実行回数は減少しませんが、クエリは関数よりもかなり高速であるため、パフォーマンスは確実に向上します

于 2012-08-03T09:23:22.710 に答える