したがって、この1つのプロジェクトでは、定期的に（1分ごとに）実行される一連のクエリがあります。「データベースエンジンでクエリを分析する」を使用してそれらをチェックしました。
それらは非常に単純です：processed='0'であるtablexから*を選択します
処理済みのインデックスがあり、各クエリは1MMレコードのテーブルで1000行未満を返す必要があります。
アナライザーは、これについていくつかの統計を作成することを推奨しました。それで、私の質問は、これらの統計は何ですか？彼らは本当にパフォーマンスを助けますか？上記のようなテーブルの場合、どのくらいの費用がかかりますか？
自分自身をSQLServerの経験豊富なユーザーと呼ぶことは決してないことを覚えておいてください...そして、このアナライザーを使用するのはこれが初めてです。
統計は、データを取得する方法の実行可能性を判断するために SQL Server が使用するものです。
たとえば、主キーにクラスター化インデックスしかないテーブルがあるとします。を実行するSELECT * FROM tablename WHERE col1=valueと、SQL Server には、テーブル内のすべての行をスキャンして一致する行を見つけるオプションが 1 つしかありません。
ここで、col1 にインデックスを追加して、SQL Server がインデックスを使用して一致する行を検索すると想定しますが、常にそうであるとは限りません。Let's say that the table has 200,000 rows and col1has only 2 values: 1 and 0. SQL Server がインデックスを使用してデータを検索する場合、インデックスにはクラスター化されたインデックス位置へのポインターが含まれます。インデックス付きの列に 2 つの値しかない場合、SQL Server は、インデックスを使用すると作業が増えるため、テーブルをスキャンするだけの方が理にかなっていると判断します。
次に、さらに 800,000 行のデータをテーブルに追加しますが、今回は値col1が大きく異なります。これは、SQL Server がインデックスを使用して、テーブルから引き出す必要があるものを制限できるため、便利なインデックスです。SQL Server はインデックスを使用しますか?
場合によります。そして、それが依存するのは統計です。ある時点で、AUTO UPDATE STATISTICSセットをオンにすると、サーバーはインデックスの統計を更新し、使用するのに非常に適切で有効なインデックスであることを認識します。ただし、その時点までは、インデックスは無関係であるとして無視されます。
これが統計の 1 つの使い方です。しかし、別の用途があり、それはインデックスとは関係ありません。SQL Server は、テーブル内のすべての列に関する基本的な統計を保持しています。価値のある異なるデータが十分にある場合、SQL Server は実際に列に一時的なインデックスを作成し、それを使用してフィルター処理を行います。これには、既存のインデックスを使用するよりも時間がかかりますが、全テーブル スキャンよりも時間がかかりません。
場合によっては、列に役立つ特定の統計を作成するための推奨事項が表示されることがあります。これらはインデックスではありませんが、列内のデータの統計的サンプリングを追跡するため、SQL Server は一時インデックスを作成してデータを返すことが適切かどうかを判断できます。
HTH
Sql Server 2005 では、自動作成統計と自動更新統計を設定します。データベース自体がこれを非常にうまく処理するため、それらを自分で作成または維持することについて心配する必要はありません。