管理スタジオでTSQLステートメントを実行し、SqlDataReaderを介して同じクエリを実行すると、後者は前者よりも速く結果を返します...
何らかの理由??
管理スタジオでTSQLステートメントを実行し、SqlDataReaderを介して同じクエリを実行すると、後者は前者よりも速く結果を返します...
何らかの理由??
1 つの可能性は、接続状態が異なることです - 特に、SET
オプションなど - 明白なもの (統計、プロファイリングなど) だけでなく、ANSI_NULLS のようなものでさえ、いくつかのクエリに大きな影響を与える可能性があります (特に xml 列、または永続化された計算列)。
また、データを読んだときにデータをどうしていますか? 表示していますか?保管?落とすだけ?SSMSは、グリッドに表示するためにテーブルのようなメカニズムでそれをバッファリングする必要があります...標準の型付きクラス(テーブルレイアウトとすでに一致している)に解析している場合、または未処理の行をドロップするだけの場合、作業は少なくなりますする。
私が思い出すと、画面もバッチで更新されます-いくつかのスレッドが進行中であることを示唆しています...ここには多くの変数があります...
SSMS で結果を表示するのにかかる時間に関連している可能性がありますか? これはおそらく結果セットのサイズに関連しています。
結果セットの大きさは?
私が実行していた Tsql クエリには、セット ベースの操作がありません...あらゆる種類のデータ型の 15 列を含む 163336 レコード セットを提供するサーバーで選択クエリを実行して、時間差を確認したかっただけです。時刻が表示される ssms の下部にあるステータス バーに時刻が表示されていることを確認しました。
SqlDataReader でも同じクエリを実行しました。そして、両方の形式のクエリリーダーで同じ選択クエリを複数回実行していました (ケースとスペースがすべて同じであることに注意してください)。
sqldatareader にかかる時間は 15 ~ 28 秒でしたが、ssms でのクエリは 29 ~ 31 秒でした...
ただし、私はそれらを同時に実行していたのではなく、交互に複数回実行していました...ネットワーク帯域幅、メモリ、またはCPU使用率が、datareaderで実行されたtsqlがssmsで実行されたものよりも優れたパフォーマンスを提供することを否定しているとは思いません