0

mssql ビューから一定範囲の行を処理するジョブを実行するアプリケーションがあります。このビューには多くの行が含まれており、追加の列 (dataid) が ID に設定された状態でデータが挿入されます。これは、取得したデータセットの範囲を知るために使用するためのものです。

少し前に、y より大きいデータ ID (y は、処理した最後の最大データ ID) を持つ上位 n 行を取得するときに、いくつかの問題が発生しました。行が正しい順序で返されていないように見えました。つまり、ある範囲の行を取得したときに、一部の行のデータ ID が間違って配置されたように見えました。 95までしか来なかった。

ウィンドウ/範囲は、各クランチで 100 行です。ただし、行のデータ ID が連続していない場合、次の 100 行を取得するクエリには、実際には次のクランチに配置されているはずのデータ ID が含まれている可能性があります。そして、次のクランチが実行されると、行がスキップされます。

dataid を使用して注文すると問題は解決しますが、それでは処理が遅くなります。これをより良い/機能する方法で行う方法について何か提案はありますか?

行数が多いと言うときは、数十億行を意味します。そうです、それが絶対に狂っていると思うなら、あなたは完全に正しいです!

Dapper を使用して、行をオブジェクトにマップします。これは完全に読み取り専用です。

この質問があいまいすぎないことを願っています。前もって感謝します!

4

3 に答える 3

2

dataid を使用して注文すると問題は解決しますが、それでは処理が遅くなります。

適切なインデックスを適用します。

「なぜクエリが遅いのか」に対する唯一の答えは、How To: Optimize SQL Queriesです。

于 2013-05-14T09:05:49.967 に答える
1

「ビュー」と「挿入」を同じ文に混ぜて何を意味するのか明確ではありません。関数を投影するビューを本当に意味する場合は、今すぐ停止できますが、機能しません。作業を再開するには、永続的なブックマークが必要です。ビューによって SELECT で射影された IDENTITY が持続性の基準を満たしていません。IDENTITY

連続した読み取りで持続する明確に定義された順序でデータを処理する必要があります。指定された順序で境界を明確に定義するキーを読み取ることができなければなりません。行のバッチ処理と同じトランザクションで処理された最後のキーを保持する必要があります。これらの要件をどのように達成するかは、完全にあなた次第です。一般的な解決策は、クラスター化されたインデックスの順序で処理し、最後に処理されたクラスター キーの位置を記憶することです。一意のクラスター化されたキーは必須です。IDENTITY プロパティとそれによるクラスター化インデックスは、必要な基準を満たしています

于 2013-05-14T09:43:29.810 に答える