SQL CLRスカラー関数を使用してHASHBYTESをシミュレートするスケーラブルな方法は何ですか？
ETLプロセスの一環として、ステージングからの行をレポートデータベースと比較して、データが最後に読み込まれてから実際に変更された列があるかどうかを確認します。 この比較は、テーブルの一意のキーと、他のすべての列のある種のハッシュに基づいています。現在HASHBYTES、このSHA2_256アルゴリズムで使用しており、多数の並行ワーカースレッドがすべて呼び出している場合、大規模サーバーではスケーリングしないことがわかりましたHASHBYTES。 96コアサーバーでテストする場合、1秒あたりのハッシュで測定されるスループットは、16を超える同時スレッドを増加させません。同時MAXDOP 8クエリの数を1〜12に変更してテストします。テストでMAXDOP 1は、同じスケーラビリティのボトルネックが示されました。 回避策として、SQL CLRソリューションを試したいと思います。要件を述べるための私の試みは次のとおりです。 関数は並列クエリに参加できる必要があります 関数は決定的でなければなりません この関数は、NVARCHARまたはVARBINARY文字列の入力を受け取る必要があります（関連するすべての列は連結されます） 文字列の一般的な入力サイズは、長さが100〜20000文字です。20000は最大値ではありません ハッシュ衝突の可能性は、MD5アルゴリズムとほぼ同等かそれ以上でなければなりません。CHECKSUM衝突が多すぎるため、機能しません。 この機能は、大規模なサーバーで適切にスケーリングする必要があります（スレッド数が増加しても、スレッドあたりのスループットが大幅に低下することはありません） Application Reasons™の場合、レポートテーブルのハッシュの値を保存できないと仮定します。これは、トリガーまたは計算列をサポートしないCCIです（他の問題もありますが、これには入りたくありません）。 HASHBYTESSQL CLR関数を使用してシミュレートするスケーラブルな方法は何ですか？私の目標は、大規模なサーバーでできる限り多くのハッシュを毎秒取得することであると表現できるため、パフォーマンスも重要です。私はCLRがひどいので、これを達成する方法がわかりません。誰かに答える動機があれば、できるだけ早くこの質問に報奨金を追加する予定です。以下は、ユースケースを非常に大まかに示すクエリの例です。 DROP TABLE IF EXISTS #CHANGED_IDS; SELECT stg.ID INTO #CHANGED_IDS FROM ( SELECT ID, CAST( HASHBYTES ('SHA2_256', CAST(FK1 AS NVARCHAR(19)) + CAST(FK2 AS NVARCHAR(19)) + CAST(FK3 AS NVARCHAR(19)) + CAST(FK4 AS NVARCHAR(19)) + CAST(FK5 …