0

SQL、特に SQL 2005 のキー、インデックス、および制約について一連の質問があります。私は約 4 年間 SQL を使用してきましたが、このトピックについて決定的な回答を得ることができたことがなく、ブログ投稿などには常に矛盾する情報があります。私が作成して使用するほとんどの時間テーブルには、Identity 列があります。は主キーであり、他のテーブルは外部キーを介してそれを指しています。

結合テーブルでは、ID がなく、外部キー列に対して複合主キーを作成します。以下は、私の現在の信念の一連のステートメントです。間違っている可能性があります。間違っている場合は修正してください。その他の質問.

だからここに行きます:

私が理解しているように、クラスター化インデックスと非クラスター化インデックスの違い (一意であるかどうかに関係なく) は、クラスター化インデックスがテーブル内のデータの物理的な順序に影響を与えることです (したがって、テーブルには 1 つしか存在できません)。非クラスター化インデックスは、ツリー データ構造を構築します。インデックスを作成するとき、クラスター化と非クラスター化を気にする必要があるのはなぜですか? いつどちらを使用する必要がありますか? ツリーを「再構築」する必要があるため、非クラスター化インデックスでは挿入と削除が遅いと言われました。クラスター化されたインデックスは、このようにパフォーマンスに影響しないと思いますか?

主キーは実際には一意のクラスター化されたインデックスにすぎないことがわかります (クラスター化する必要がありますか?)。主キーとクラスター化された一意のインデックスの違いは何ですか?

制約も見たことがありますが、実際に使用したり、実際に見たりしたことはありません。Constraints の目的はデータの整合性を強化することであるのに対し、Index はパフォーマンスを目的としているとのことでした。また、制約は実際にはインデックスとして実装されているため、「同じ」であることも読みました。これは私には正しく聞こえません。制約はインデックスとどう違うのですか?

4

5 に答える 5

2

クラスター化されたインデックスは、正しく言えば、テーブル内のデータが物理的に格納される方法に関する定義です。つまり、クラスター化キーを使用して並べ替えられた B ツリーがあり、データがリーフ レベルにあります。

一方、非クラスター化インデックスは個別のツリー構造であり、リーフ レベルではクラスター化キー (またはテーブルがヒープの場合は RID) のみを持ちます。つまり、非クラスター化インデックスを使用する場合は、クラスター化インデックスを使用して他の列を取得します (非クラスター化インデックス キー列を構成する列のみを要求した場合に、要求が非クラスター化インデックスによって完全にカバーされている場合を除きます)。

いつどちらを使用する必要がありますか? クラスター化インデックスは 1 つしか持てないため、最も理にかなった列に定義します。つまり、ほとんどの場合 ID でクライアントを検索する場合は、ID にクラスター化インデックスを定義します。非クラスター化インデックスは、あまり使用されない列に定義する必要があります。

パフォーマンスに関しては、インデックス キーを変更する挿入または更新は、ページ分割が発生する可能性があるため、クラスター化されていないインデックスでクラスター化されているかどうかに関係なく、常に苦痛です。リーフレベルにより多くのデータがあるため、より多くの害があります)。したがって、一般的なルールは、インデックス キーを変更したり、新しい値を挿入したりして、それらが順次になるようにすることを避けることです。そうしないと、断片化が発生し、定期的にインデックスを再構築する必要があります。

最後に、制約に関しては、定義上、インデックスとは何の関係もありませんが、SQL サーバーはインデックスを使用してそれらを実装することを選択しました。たとえば、現在、一意の制約はインデックスとして実装されていますが、これは将来のバージョンで変更される可能性があります (私はそうなるとは思いませんが)。インデックスの種類 (クラスター化されているかどうか) は自由ですが、クラスター化されたインデックスは 1 つしか持てないことに注意してください。

この種の質問が他にもある場合は、これらのトピックについて詳しく説明しているこの本を読むことを強くお勧めします。

于 2009-09-10T08:16:38.483 に答える
1

クラスター化されたものとクラスター化されていないものについてのあなたの仮定はかなり良いです

また、主キーはnull以外の一意性を強制しているようですが、一意のインデックスはnull以外のプライマリと一意を強制していないようです

于 2009-09-10T08:09:01.217 に答える
1

キーは、リレーショナル データベース理論における論理的な概念です。これは、行を一意に識別するように設計されたキー (および通常はインデックス) です。したがって、一意である必要があり、NULL にすることはできません。

クラスタリング キーは、特にSQL Server のストレージ物理概念です。これは、ルックアップなどに使用されるだけでなく、テーブル内のデータの物理構造も定義する特別なインデックスです。西ヨーロッパ文化 (おそらくアイスランドを除く) の印刷された電話帳では、クラスタ化されたインデックスは "LastName, FirstName" になります。

クラスタリング インデックスは物理的なデータ レイアウトを定義するため、それらのうちの 1 つしか持つことができません (または何も持たない - ただし、お勧めしません)。

クラスタリング キーの要件は次のとおりです。

  • 一意である必要があります (そうでない場合、SQL Server は 4 バイトの "uniqueifier" を追加します)
  • 安定している必要があります (決して変化しない)
  • 可能な限り小さくする必要があります(INTが最適です)
  • 増え続けるはずです(IDENTITYと考えてください)

SQL Server では、既定でプライマリ キーがクラスタリング キーになりますが、必要に応じて変更できます。また、注意してください: クラスタリング キーを構成する列は、テーブルのすべての非クラスタ化インデックスのすべてのエントリに追加されるため、クラスタリング キーをできるだけ小さく保ちます。これは、クラスタ化キーが「ブックマーク ルックアップ」を実行するために使用されるためです。非クラスタ化インデックス (社会保障番号による人など) でエントリを見つけた場合、データの行全体を取得する必要があります。詳細を取得するには、ルックアップを行う必要があります。このために、クラスタリング キーが使用されます。

優れた、または有用なクラスタリングおよび/または主キーを作成するものについては、大きな議論があります。これについて読むための優れたブログ投稿がいくつかあります。

マルク

于 2009-09-10T08:16:09.013 に答える
1

いくつか質問があります。私はそれらのいくつかを分解します:

インデックスを作成するとき、クラスター化と非クラスター化を気にする必要があるのはなぜですか?

行がどのように編成されているかが気になる場合があります。それは、データとその使用方法によって異なります。たとえば、主キーが の場合、GUID 値は基本的にランダムであるため、uniqueidentifierそれを にしたくない場合があります。CLUSTEREDこれにより、SQL がテーブル全体にランダムに行を挿入し、ページ分割が発生してパフォーマンスが低下します。主キーの値が常に連続して増加する場合 (int IDENTITYたとえば)、おそらくそれを にしたいCLUSTEREDので、テーブルは常に最後に大きくなります。

主キーはCLUSTEREDデフォルトで設定されており、ほとんどの場合、気にする必要はありません。

ツリーを「再構築」する必要があるため、非クラスター化インデックスでは挿入と削除が遅いと言われました。クラスター化されたインデックスは、このようにパフォーマンスに影響しないと思いますか?

実際には、その逆もありえます。 NONCLUSTEREDインデックスは個別のデータ構造として保持されますが、構造は「再構築」する必要なく、ある程度の変更ができるように設計されています。インデックスを最初に作成するときに、インデックスのFILLFACTOR各ページに残す空き領域を指定する を指定できます。これにより、インデックスは、ページ分割が必要になる前に多少の変更を許容できます。ページ分割が発生する必要がある場合でも、インデックス全体ではなく、隣接するページにのみ影響します。

インデックスにも同じ動作が適用されCLUSTEREDますが、インデックスは実際のテーブル データを格納するため、インデックスでのページ分割操作は、行全体を移動する必要がある可能性があるため (インデックス内CLUSTEREDのキー列と だけではなく)、はるかにコストがかかる可能性があります。ROWIDNONCLUSTERED

FILLFACTOR次の MSDN ページでは、ページ分割 について説明しています: http://msdn.microsoft.com/en-us/library/aa933139(SQL.80).aspx

主キーとクラスター化された一意のインデックスの違いは何ですか? 制約はインデックスとどう違うのですか?

これらの両方について、自分の意図を宣言することが重要だと思います。何かを呼び出すと、PRIMARY KEYそれが特定の行を識別するための主要な方法であることを宣言しています。は とPRIMARY KEY物理的に異なりCLUSTERED UNIQUE INDEXますか? わからない。動作は基本的に同じですが、データベースを操作しているユーザーにとって意図が明確でない場合があります。

制約に関しては、さまざまな種類の制約があります。aの場合、意図を宣言する以外に、それとUNIQUE CONSTRAINTa の間に実際の違いはありません。制約、制約、制約UNIQUE INDEXなど、インデックスの種類に直接マップされない他の種類の制約があります。CHECKDEFAULTFOREIGN KEY

于 2009-09-10T08:19:59.560 に答える
0

私はこれに深く答える時間がないので、ここに私の頭のてっぺんからいくつかの情報があります:

あなたはクラスター化インデックスについて正しいです。クラスター化されたインデックスのソート順に従って、物理データを再配置します。クラスター化インデックスは、特に範囲限定のクエリ(日付間など)に使用できます。

PKはデフォルトでクラスター化されていますが、クラスター化されている必要はありません。これは単なるデフォルト設定です。PKは、行のUIDであると想定されています。

制約はインデックス(たとえば、一意の制約)として実装できますが、デフォルト値として実装することもできます。

于 2009-09-10T08:07:19.190 に答える