私は現在、古いデータベースをより新しいスタイルに変換するプログラムに取り組んでいます。私が割り当てたタスクの1つは、古いバイナリ列を削除し、それらをリポジトリのドキュメントに変換することです。.NET - クエリが完了する前にDataReaderからの読み取りを開始しますか？
テーブルには約110万行があり、処理には約12時間かかります。
私はこのすべてを少し速くする方法を探しています。私が見ていることの1つは、データをすばやく取得することです。それが完了する前に私のクエリの結果に到達する方法があれば？私は、クエリアナライザでこのテーブルに対して "select *"ステートメントを実行するとすぐに結果が返ってくることに気がつきましたが、.NETでExecuteReaderを使用すると、クエリの実行に30分ほどかかることがあります。 。
command.ExecuteReader(CommandBehavior.SequentialAccess)を使用すると役立つことがあります。ただし、これを行うには、列を順番に読み取る必要があり、バイナリ値を別の方法で読み取る必要があります。私はreading the documentation on SequentialAccessをお勧めしますので、あなたのコードに対するその他の変更が必要な場合があります。
同じクエリがクエリアナライザで即座に実行されることを考慮してください。これは、クエリが最初の結果を返すために本質的に30分かかっていないか、クエリアナライザで実行されることを示しています。私は大きなバイナリ値の扱いがこの不一致の可能性のある説明だと思います。 1つの簡単なテスト方法は、バイナリ列を除いてすべてを選択するクエリを変更し、ExecuteReaderがかかる時間を変更するかどうかを確認することです。実行時間がバイナリ列なしで同じ場合、SequentialAccessが役立つことはほとんどありません。バイナリ列がない方が速い場合は、SequentialAccessを使う価値があります。
QAでクエリを完全に返しても30分かかりますが、すぐにデータの一部をすぐに返し始めます。SqlCommand.BeginExecuteReaderを使用してコード内のエフェクトをレプリケートすることができました。 –
私のパフォーマンスの向上の大半はSqlCommand.BeginExecuteReaderの使用に由来していましたが、これも良い影響をもたらしました。合計時間がダウンしています12時間から1.5時間。 –
クエリのすべての列が必要ない場合は、select *を使用しないでください。おそらくこの質問も役に立ちます：Performance optimization strategies of last resort
実際のコードはどのように見えますか？索引付けされていない列に対して重いwhere-queriesがあるようです。複数の列でフィルタリングせずにプレーンなSELECTを実行すると、ExecuteReaderでも高速に処理できます。 –
クエリを分割して少数の行に分割し、いくつかのスレッドを実行してそれらを処理できますか？ – clyc
@パウリ - 問題はデータの量ほどのインデックスではありません。私はいくつかのBLOB列を扱っています。 :( –