Dapper dot net にはbufferパラメーター (bool) がありますが、私が知る限り、それが行う唯一のことは、結果を返す前にリストにキャストすることです。
ドキュメントに従って：
Dapper のデフォルトの動作は、SQL を実行し、リターン時にリーダー全体をバッファリングすることです。これは、データベース内の共有ロックを最小限に抑え、データベースのネットワーク時間を削減するため、ほとんどの場合に理想的です。
ただし、巨大なクエリを実行する場合は、メモリ フットプリントを最小限に抑え、必要なオブジェクトのみを読み込む必要がある場合があります。これを行うには、 buffered: false を Query メソッドに渡します。
結果をリストにキャストする方法がこれを達成するかどうかはわかりません。何か不足していますか？私の唯一の考えは、 を to に設定することになっているということですCommandBehavior(ExecuteReaderしかしCommandBehavior.SequentialAccess、そうではありません)。
しかし、私が知る限り、それが行う唯一のことは、結果を返す前に結果をリストにキャストすることです。
あなたは何も見逃していません。それが重要な違いです。それ自体がキャストではないことを除いて、実際に返されるオブジェクトは大きく異なります。基本的に、データを読み取る方法は2つあります。
非常に大量のデータ（数千から数百万の行）を読み取る場合は、バッファーなしのAPIが望ましい場合があります。そうしないと、大量のメモリが使用され、最初の行が使用可能になるまでに顕著な遅延が発生する可能性があります。ただし、最も一般的なシナリオでは、読み取られるデータの量は妥当な制限内であるため、呼び出し元に渡す前にリストにプッシュするのが妥当です。これは、コマンド/リーダーなどが戻る前に完了していることを意味します。
補足として、バッファモードは、非常に一般的な「接続上にすでに開いているリーダーが存在する」（または正確な言い回しが何であれ）ことも回避します。
これについて@chris-marisicに同意する必要があります... buffered:truedata.ToList()を使用しているときに、その正確な行 ( )で複数の「メモリ不足」例外に遭遇しました。これは「無数の行 × 無数の列」のクエリではなく、約 30 列の通常の 5 ～ 6,000 行の SQL 結果でした。
それは本当にあなたの構成に依存します。たとえば、SQL と IIS が同じ物理マシンで実行されているかどうか。また、IIS マシンにインストールされているメモリの量、ページ ファイルの設定など。Web サーバーが 2 GB 以下の場合は、非常に重いレポート用に "buffered:false" を設定することを検討してください。
実際には、決して使用 buffered: falseしない方がよいでしょう。
何百万もの行を読んでも、バッファリングされていない結果よりもバッファリングされた結果を使用する方が高速でメモリ効率が高いことがわかりました。テーブルに 500 列があり、数千万行または数億行を読み取っている場合、クロス オーバー ポイントが存在する可能性があります。
結果セットが数十億の値よりも小さい場合buffered: false、何らかの理由で使用する価値はありません。
実際の分析中に、Sql Server からのギガバイトのデータの読み取りが、標準のバッファー モードで高速 (2 ～ 6 倍) であり、メモリ効率が高いことにショックを受けました。パフォーマンスの向上は、サイズ変更されない配列へのインデックスによってスパース配列にオブジェクトを追加する、可能な限り細かい操作を考慮に入れています。マルチギガバイトのスパース配列を使用して、バッファなしからバッファありに切り替えると、ロード時間が 2 倍改善されました。buffered を使用してディクショナリに書き込むと、何百万ものレコードを挿入するときにロード時間が 6 倍改善されました (ディクショナリはテーブルの int PK をキーとして使用し、可能な限りハッシュコード計算の基本として使用しました)。
パフォーマンスに関するすべてと同様に、常に分析する必要があります。ただし、非常に高いレベルの確実性で、常にDapperのデフォルトのバッファリングされた動作から開始すると言えます。