問題タブ [logical-reads]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql-server - 単一行の削除での多数の「論理読み取り」
PrimaryKeyによってテーブルから行を削除すると、約44472の論理読み取りが発生します。これで、テーブルには、ForeignKeysを削除するテーブルのPKにリンクする5〜6個の子テーブルがあります。
削除のパフォーマンスを改善するために何をすべきかわかりません。
助言がありますか ？
編集： 削除用のクエリプランを追加しました
http://img384.imageshack.us/img384/6255/deleteexecutionplan.png
編集： 私は解決策を見つけました（それが理想的な解決策であるかどうかはわかりません）-それは以下の応答にあります。
.net - 論理読み取りの単体テスト SQL
データアクセスレイヤーの単体テストがあります。これは、SQL 構文エラーを見つけるのに役立ちました。
これらのテストが完了したので、さらに一歩進めたいと思います。単体テストを実行して、論理読み取りの数が多い sql を自動的に見つけたいと思います (チューニングが必要な sql を見つけるため)。
「set statistics IO」をSQLに追加することは難しくありません。私が探しているのは、データベースに送信するストアド プロシージャであり、SQL に関する論理読み取り情報を含む文字列を返します。私は Sybase で作業していますが、別の DB でこれを行うストアド proc/etc を知っていれば、それは大きな助けになります。
ありがとう！
sql - SQL論理読み取り
大きな行セットに対して呼び出される関数内にあるため、多くのクエリが実行されます。
クエリはSELECT @sql = NULL WHERE @sql = ''
これは私に0の物理的な読み取りを示していますが。
約17000の論理読み取りが表示されます。
説明はありますか？
sql-server - SQL クエリがより多くのページを読み取るのに高速なのはなぜですか?
ビュー内のテーブルに追加されるいくつかの非クラスタ化インデックスをテストしていました（7つの内部結合があります）。Tunning Advisor (SQL Server 2008) を実行すると、テーブル (a) に非クラスター化インデックスを作成するスクリプトが表示され、クエリの最適化に役立ちます。
インデックスを作成する前に、クエリを実行して IO および TIME 統計を取得しました。
nonClustered インデックスを作成した後、次のようになりました。
AとCの行を確認してください。Aでは 300 ページ多く、 Bでは 32 ページ少ないだけです。では、なぜこのクエリの方が速いのでしょうか? クエリが読み取るページが多いほど、パフォーマンスが低下するといつも思っていました
sql - 論理読み取りでインデックス作成がどのように機能するか、およびその利点は何ですか
論理読み取りを減らして、ストアド プロシージャの実行時間を短縮したいのですが、SQL サーバーです。後で、インデックスを使用することで解決策を見つけることができます。
インデックス作成の仕組みとその利点を知る必要があります。
sql-server - 内部結合とWHERE句のサブクエリSQLサーバー
ストアド プロシージャを高速化しようとしているので、以下のような統計 io を使用して 2 つの形式でストアド プロシージャをテストします。
方法 1: 結合を使用する
統計結果を次のように取得します
方法 2: where 句のサブクエリを使用する
統計結果を次のように取得します
どちらを使用するのが最適かを知る必要がありますか?
ここで論理読み取りがどのように機能するかについて説明が必要ですか?
sql-server - SQL Server での論理読み取りの数
SQLサーバーがデータにアクセスする方法を理解しようとしています。
非常に単純なクエリの場合、必要な論理読み取りの数を正確に計算できますが、かなり単純なクエリに従うことに問題があります。
これはテーブルを生成するコードです:
クエリプランは次のとおりです。
クエリ統計は次のとおりです:
(影響を受ける 771 行) テーブル 'TT_TMP_3'。スキャン カウント 771、論理読み取り 2429、物理読み取り 0、先読み読み取り 6、LOB 論理読み取り 0、LOB 物理読み取り 0、LOB 先読み読み取り 0。
テーブル 'TT_TMP_4'。スキャン カウント 1、論理読み取り 3、物理読み取り 0、先読み読み取り 0、LOB 論理読み取り 0、LOB 物理読み取り 0、LOB 先読み読み取り 0。
TT_TMP_4 には 771 行あるため、771 回のインデックス シークが必要です。各シークには 2 つの論理読み取りが必要です。次に、見つかった行ごとに、列 x の値を見つけるために RID_lookup を実行する必要があります。これにより、さらに 771 回の論理読み取りが可能になります。合計で 2313 の読み取りがあり、まだ 116 が欠落しています。
質問:これらの 116 の論理読み取りは何のためですか?