SQL Serverのパフォーマンスに影響するキーポイント

まず、論理データベースとテーブルの設計

テーブルとテーブル間の関係を含むデータベースの論理設計は、リレーショナルデータベースのパフォーマンスを最適化するための中核です。優れた論理データベース設計は、データベースとアプリケーションを最適化するための優れた基盤を築くことができます。

標準化されたデータベースロジック設計では、多数の列のうち長い列を大きくて相互に関連した狭いテーブルに置き換える必要があります。標準化されたテーブルを使用する利点のいくつかはここにあります。

A：テーブルが狭いため、並べ替えやインデックス作成を高速化できます。

B：マルチテーブルのため、たくさんのインデックスが可能です。

C：より狭くてコンパクトなインデックス。

D：各テーブルに含まれるインデックスは少なくてもかまいません。したがって、多くのインデックスの場合、これらの操作はシステムパフォーマンスに大きな影響を与えるため、挿入、更新、削除などの速度を上げることができます。

E：NULL値が少なくなり、余分な値が少なくなり、データベースがコンパクトになります標準化により、データ取得時の参照テーブルの数とそれらの間の接続関係の複雑さが増します。あまりにも多くのテーブルと複雑な接続はサーバーのパフォーマンスを低下させる可能性があるので、この2つを総合的に考慮する必要があります。

相関を使用して主キーと外部キーを定義する際に注意する主な点は、次のとおりです。複数のテーブルを結合するために使用される主キーと参照されるキーは同じデータ型を持つ必要があります。

次に、インデックスの設計

A：テーブルスキャンを避けます。

クエリのwhere句を確認してください。これがオプティマイザの重要な焦点です。 whereに含まれる各列は可能な候補インデックスです最適なパフォーマンスを達成するために、where句で与えられた列column1に対して以下の例を検討してください。

次の2つの条件は、インデックスの最適化されたクエリのパフォーマンスを向上させることができます。

1番目：テーブルのcolumn1列に単一のインデックスがあります;

2番目：テーブルに複数のインデックスがありますが、column1は最初のインデックスの列です。

複数のインデックスを定義しないでください。column1は2番目以降のインデックスです。このようなインデックスはサーバーのパフォーマンスを最適化することはできません。

次に例を示します。次の例では、pubsデータベースを使用しています。

SELECT au_id、au_lname、au_fnameの投稿者

WHERE au_lname = 'White'

以下の列に作成されたインデックスは、オプティマイザにとって有用なインデックスです。

au_lname

au_lname、au_fname

次の列に作成されたインデックスは、オプティマイザには適しません。

au_address

au_fname、au_lname

1つまたは2つの列にナローインデックスを使用することを検討してくださいナローインデックスはマルチインデックスおよびコンポジットインデックスよりも効率的です。狭いインデックスでは、各ページの行数が増え、インデックスレベルが少なくなり（複数のインデックスや複合インデックスとは対照的に）、システムパフォーマンスが向上します。複数列インデックスの場合、SQL Serverはすべての列インデックスと（最初のインデックスの）ヒストグラム統計について（共用体の）密度統計を維持します。統計によると、複合インデックスの最初のインデックスがめったに使用されない場合、オプティマイザは多くのクエリ要求にインデックスを使用しません。

有用なインデックスは、insert、uodate、deleteを含むselect文のパフォーマンスを向上させますが、テーブルの内容を変更するとインデックスに影響します。 insert、update、deleteの各文はパフォーマンスを低下させます。実験によれば、単一のテーブルで大量のインデックスを使用したり、共有列でオーバーラップインデックスを使用したりしないでください（つまり、参照制約は複数のテーブルで使用されます）。

列の一意のデータ数を確認し、それを表の行数と比較します。これはデータの選択性であり、この比較の結果は、列を候補索引として使用するかどうか、また使用する場合はどの索引を作成するかを決めるのに役立ちます。次のクエリを使用して、列内のさまざまな値の数を返すことができます。
table_nameからcount（個別のcloumn_name）を選択します。

column_nameが10000行のテーブルであると想定し、column_nameの戻り値を見て、使用する必要があるかどうか、および使用するインデックスを決定します。

ユニークな値インデックス

5000非クラスタインデックス

20クラスタインデックス

3インデックスなし

镞インデックスと非インデックスの選択

< 1>インデックスは行の物理的な順序であり、インデックスの順序は一貫しています。実際のデータページは、ページレベル、低レベルなどのインデックスの各レベルに含まれています。テーブルには1つのインデックスしか持てません。更新のため、deleteステートメントは比較的多くの読み取り操作を必要とするため、索引はしばしばそのような操作を高速化することができます。少なくとも1つのインデックスを持つテーブルでは、インデックスが必要です。

次のような場合、インデックスの使用を検討できます。

たとえば、列に含まれるさまざまな値の数は限られています（ただし、非常にまれではありません）。

customerテーブルの州リストには、約50の州名の省略値がリストされています。

次に例を示します。<>、> =、<、< =などの間の列に作用する列など、値の範囲を返す列には镞インデックスを使用できます。

select * from sales where ord_date '5/1/93'から '6/1/93'の間

次に例を示します。クエリで多数の結果を返す列では、インデックスを使用できます。

SELECT * FROM phonebook WHERE last_name = 'Smith'

多数の行がテーブルに挿入されている場合は、このテーブルに自然に成長するカラム（たとえば、identityカラム）を避けてください。その上にインデックスを作成します。欠陥のあるインデックスを作成すると、挿入のパフォーマンスが大幅に低下します。挿入された各行は、テーブルの最後のページ、つまりテーブルの最後のデータページに移動する必要があるためです。

データが挿入されているとき（このページがロックされているとき）は、現在の挿入が終了するまで、他のすべての挿入された行が待機する必要があります。

インデックスのリーフページには実際のデータページが含まれており、ハードディスク上のデータページの順序はインデックスの論理的な順序と同じです。

< 2>インデックスの順序が並んでいないと、行の物理的な順序が異なります。非hインデックスのリーフレベルには、行データページへのポインタが含まれています。

1つのテーブルに複数の非Nインデックスが存在する可能性があり、次のような場合に非Nインデックスを使用することを検討できます。 *部品表
に記載されているpart_id

を選択：

列インデックスに多くの異なる値については、非矢印

ログイン

例と考えることができますemp_id = 'pcm9809f'の従業員から

クエリステートメントでorder by句を使用して、列に镞インデックスを使用することを検討できます。

3番目に、クエリステートメントの設計

クエリステートメントの分析によるSQL Serverオプティマイザは、自動的にクエリを最適化し、最も効果的な実装を決定します。オプティマイザはクエリを分析してどの句を最適化できるかを判断し、クエリに対して最適化できる句の有用なインデックスを選択します。最後に、オプティマイザはすべての実行シナリオを比較し、最も効率的なシナリオを選択します。

クエリを実行するときは、where句を使用して、処理する必要がある行数を制限します。必要でない限り、1つのテーブル内ですべての行を無制限に読み取って処理することは避けてください。

たとえば、次の例では、stor_id = 7131で販売から数量を選択します。

は、次の無制限クエリよりも効率的です。

select qty販売から

多数の結果セットを顧客の最終データ選択に戻すことは避けてください。結果セットのサイズを制限するという目的を満たす関数をSQL Serverで実行できるようにするとより効率的です。

これにより、ネットワークI /Oが減少し、マルチユーザー関連の同時実行性に対するアプリケーションのパフォーマンスが向上します。オプティマイザの焦点は、有用なインデックスを利用するためのwhere句のクエリです。テーブル内の各インデックスは、where句に含まれる候補インデックスになることがあります。最高のパフォーマンスを得るために、特定の列column1について以下の索引に従ってください。

1つ目：テーブルのcolumn1列に1つのインデックスがあります;

2つ目：テーブルに複数のインデックスがありますが、column1はwhereサブではなく最初の列のインデックスになりますセンテンスにcolumn1列インデックスのないクエリを使用し、where句で複数のインデックスを持つ最初以外のインデックスにインデックスを付けないようにします。

この時点では、複数のインデックスは役に立ちません。

たとえば、au_lnameに複数列のインデックスがある場合、

pubsデータベースのauthorsテーブルのau_fname列には、次のようになります。

次のクエリステートメントau_lnameのインデックスを利用する

SELECT au_id、au_lname、au_fname作者からの投稿

WHERE au_lname = '白'

AND au_fname = 'ジョンソン'

SELECT au_id、au_lname、au_fname作成者からの投稿

WHERE au_lname = 'White'

次のクエリでは、先頭以外のインデックスのマルチインデックスインデックスが使用されているため、インデックスは使用されません。

SELECT au_id、au_lname、au_fnameの著者からのアクセス

WHERE au_fname = 'Johnson'