インデックスが無効になると、定義はシステムカタログに残りますが、使用されなくなります。 SQL Serverはインデックスを維持せず(テーブルのデータが変更されるため)、インデックスを使用してクエリを満たすことはできません。 クラスター化インデックスが無効になっている場合、テーブル全体にアクセスできなくなります。
Bツリーを破棄してテーブルから直接データにアクセスできないのはなぜですか? (ほとんどの場合、テーブルを行ごとにスキャンすることにより)データに完全にアクセスできないようにするよりも適切でしょうか?
それは純粋に理論的な質問です-私は実際にはそうしません。それはシナリオでも、やることでもありません。なぜそうなるのかを知りたいのですが、内部的な問題だと考えてください。
Bツリーを破棄してテーブルから直接データにアクセスできないのはなぜですか? (ほとんどの場合、テーブルを行ごとにスキャンすることにより)、アクセスできないデータよりも適切ではないでしょうか?
あなたの質問に答えるために、インデックス作成の基本がより便利になります-インデックスは、Bツリー構造で編成された一連のページ(インデックスノード)で構成されます。この構造は本質的に階層的であり、ルートノードが階層の最上部にあり、リーフノードが最下部にあります。詳細は こちら を参照してください。
また、多くの人が説明したように、クラスター化インデックス== 1つ以上のキーまたは列で物理的に順序付けられた元のテーブル。そのため、クラスター化インデックスが無効になっていると、そのデータ行にアクセスできません。データを挿入することはできません(非クラスター化インデックスの場合、挿入は成功しますが、これは完全にこの投稿に関連しているわけではありません-ここではクラスター化インデックスについての議論なので)。また、再編成操作も機能しません。
以下で詳しく説明します。
[〜#〜] clustered [〜#〜]インデックスを無効にした場合の影響を確認するために、Adventureworksデータベースを使用します。
次に、テーブルの行数を確認します。
クラスタ化インデックスを無効にします
次に、テーブルから行数を選択します。今回は以下のメッセージでエラーになります:
再編成操作でも動作しません!!
クラスタ化インデックスを再構築すると、正常に機能するはずです。
テーブルを選択して、データにアクセスできるかどうかを確認します
つまり、クラスタードインデックスを無効にすると、テーブル内のデータは引き続き存在しますが、ドロップまたはREBUILD操作以外にはアクセスできなくなります。関連するすべての非クラスター化インデックスとビューは使用できなくなり、テーブルを参照している外部キーも無効になり、テーブルを参照しているすべてのクエリでFAILUREが発生します。
注:インデックスを有効にするオプションはありません。あなたはそれを再構築する必要があります。
B +ツリーのリーフレベルはテーブルです。 CIを無効にすることで何を達成したいですか?データにアクセスできないようにしたくない場合は、これを行わないでください。
なぜSQL Serverがこれを許可するのかさえよくわかりません。
CREATE TABLE T
(
X INT CONSTRAINT PK PRIMARY KEY CLUSTERED,
Y INT CONSTRAINT UQ UNIQUE NONCLUSTERED
);
ALTER INDEX PK ON T DISABLE;
...また、NCIを無効にするので、それによってカバーされるSELECT
クエリも無効になります。これのユースケースは考えられません。 - martin-smith
私が頭で考えることができる唯一の用途は、まさに議論されていることです。テーブルを無効にします。 dbo
やsysadmin
であっても、誰にも触れてほしくないテーブルがある場合は、クラスター化インデックスを無効にできます。テーブルはデータとともに存在しますが、クラスター化インデックスを再度有効にするまで完全にアクセスできません。 - ケネスフィッシャー