web-dev-qa-db-ja.com

SQLサーバーの論理読み取りとは何ですか?論理的なのを減らす方法は?

すべての検索から、SQLサーバーでのクエリを高速化するために、ソースは適切なwhere句を使用して論理読み取りを削減すると述べました。実際には、フロントエンドからのリクエストを受け取ったときにSQLサーバーのストアドプロシージャがどのように機能するかを知る必要があります。

23
Nandha

論理読み取りとは、データベースから読み取るレコードを意味します。小さくて愚かな例を見てみましょう。

select *
from
(
  select *
  from orders
  where client = 1234
)
where item = 9876;

ここで、クライアント1234からすべての注文を選択します。その後、アイテム9876の注文のみを取得します。そのため、(オプティマイザがこれを確認せず、クエリを内部で最適化する場合)最初のステップで必要以上のレコードを選択します。 1つのステップで両方の基準を適用することにより、論理読み取り(およびそれに対応する大き​​な中間結果)を削減します。

select *
from orders
where client = 1234
and item = 9876;

(これは物理的な読み取りにも影響する可能性がありますが、必ずしもそうである必要はありません。たとえば、最初のクエリは100レコードにアクセスしてから10に減らすことができますが、2番目は10レコードのみを読み取ります。ので、両方のステートメントが1つのディスクブロックを読み取ります。つまり、1つの物理読み取りを行います。データが既にdbmsキャッシュ、つまりメモリにある場合、物理読み取りが0になることもあります。読み取りはクエリごとに異なる場合がありますが、クエリとデータが変更されない限り、論理読み取りは同じままです。

23

廃止されたSQL Server 2000テクニカルドキュメント (p387、元はSQL Server Architecture(SQL Server 2000)の一部)の一部であるMicrosoftホワイトペーパーには、適切な定義があります。

SQL ServerのインスタンスからのI/Oは、論理I/Oと物理I/Oに分けられます。 論理読み取りは、データベースエンジンがバッファーキャッシュからページを要求するたびに発生します。ページが現在バッファーキャッシュにない場合、物理読み取りは次に、ページをバッファキャッシュに読み込むために実行されます。ページが現在キャッシュにある場合、物理的な読み取りは生成されません。バッファキャッシュは、すでにメモリ内にあるページを使用するだけです。

したがって、論理読み取りとは、クエリエンジンがデータを読み取る必要がある場合です。まず、メモリ内を検索します。ページが既にSQL Serverのメモリにある場合は、それを使用します。メモリで見つからない場合、物理読み取りがトリガーされ、データページがディスクから読み取られます。後続の物理読み取りなしの論理読み取りは、基本的に「キャッシュヒット」です。

バッファキャッシュ(バッファプールとも呼ばれます)は、クエリを解決するためのSQL Serverの主な作業メモリです。 SQL Serverが使用するメモリ量を設定すると、使用可能なバッファーキャッシュのサイズを制御します。

ただし、クエリを見たり、テーブルに何が含まれていて、データがどのように見え、どのようにインデックス付けおよび編成されているかを知ることなく、何をする必要があるかを伝えることは基本的に不可能です。

多数の論理読み取りが必ずしも悪いわけではないかもしれません-あるいは、必ずしもpreventableではありません。悪いのは、論理的な読み取りのinordinate数です。 3行のデータを返しているが、クエリエンジンがテーブルの2億行をスキャンする必要がある場合、それは非常に遅くなり、クエリを書き換えるかインデックスを追加することでおそらく改善できます。

まず、ストアドプロシージャのクエリがどれほど複雑かを見ていきます。特に、欠落しているインデックスを探します。 SELECT * FROM BigTable WHERE ProductDate >= '01/01/2014'を実行している場合、ProductDateにインデックスがあったことを確認します。ただし、SELECT * FROM BigTable ORDER BY ProductDate DESCを実行している場合、はい、インデックスは引き続き役立ちますが、データセット全体を返す必要があるため、とにかくテーブル全体を読み取る必要があります。また、論理読み取りはpage読み取りを参照するため、問題のProductDateがディスク全体に均等に分散している場合は、すべてのページまたはほぼとにかくすべてのページ。

さらに、テーブルの統計が最新ではない可能性があります。テーブルに20,000行を追加しても、SQL Serverがまだ2000行しかないと考えている場合、クエリの計画は完全に破棄されます。

41
Bacon Bits