SQL Server データベースで数百万行のセットを操作する必要があります。
ほとんどすべてのコマンドでこのMERGE
ステートメントを使用しています。あちらこちらで、このテーブルとあのテーブルを合体させます。私はそれが最高のパフォーマンスを提供すると信じているので、そのためにストアドプロシージャを使用します。
プロセスが遅すぎることがわかりました(2kk行のマージ-5〜50秒のランダムに見える)。つまり、パフォーマンスは最高に見えるほどではなく、何らかの理由で理由を見つけることができませんでした: タスク マネージャーとリソース モニターを開き、負荷の高いMERGE
クエリをいくつか開始し、実際の実行計画にスキャンやその他の不快な項目が含まれていないことを確認しました。また、CPU、メモリ、およびディスク ドライブの消費量が非常に少ないことがわかりました。この理由はまだ私にはわかりません。
最近、メモリ最適化テーブルとネイティブ ストアド プロシージャを組み合わせると、パフォーマンスが向上することもわかりました。
Merge
は MO テーブルでは使用できず、MO テーブルはネイティブ ストアド プロシージャでは使用できないことがわかりました。
MSDN で Merge を代用する唯一の例は、while ループと追加の列 RowId に基づいて「インデックスで行にアクセスする」という奇妙なアプローチを使用しています。さらに詳しい情報を学び、MSDN の例を繰り返し、その列に多数のバケット (8kk) を持つハッシュ インデックスを確立しました。実際、パフォーマンスがいくらか向上しました。
ただし、繰り返しますが、ループ内の各反復には、少なくとも 2 つのインデックス シークと、条件が満たされた場合の挿入/更新/削除が必要です。
だから私は尋ねます:本当にパフォーマンスの高い を配置するための有用な戦略はありますmerge
か? 私にはわかりませんが、CLR プロシージャを作成する方法はありますか? そのほうがいいでしょうか?他のヒントやヒントはありますか?