☰

クラスター化された PK を削除して新しい PK を追加すると、行の順序はどうなるでしょうか?

tag-icon • tag-icon sql-server indexes
クラスター化された PK を削除して新しい PK を追加すると、行の順序はどうなるでしょうか?

SQL Server では、現在 uniqueidentifier クラスター化主キーを持つ TableA を確認しています。GUID はどのコンテキストでも意味を持ちません。

(キーボードとモニターを片付けて、ソーダを置くのに少し時間をあげます。)

その主キーを削除し、テーブルに新しい一意の整数主キーを追加したいと思います。質問は次のとおりです。インデックスを削除し、列を uniqueidentifier から int に変更し、変更した列に新しいクラスター化された一意の主キーを追加すると、新しい PK 値はテーブルに挿入された順序になりますか、それとも別の順序になりますか? これは正しい方法ですか? これは機能しますか? (私はテーブルの作成/変更に関しては初心者です。)

答え1

クラスター化インデックスを削除すると、テーブルはヒープになります。ヒープはインデックスとはまったく異なる物理構造を持っているため、データを新しい構造にコピーする必要があります。ヒープにはまったく順序がありません。新しいクラスター化インデックスを追加すると、データはヒープから新しいインデックスにコピーされ、順序は新しいクラスター化キーによって定義されます。

既存の順序を維持したい場合は、新しい整数 ID を適切に割り当てるだけです。

ALTER TABLE Table ADD Integer_Id INT;
GO

WITH cte AS (
  SELECT ROW_NUMBER() OVER (ORDER BY Guid_Id) as RowOrderByGuid,
    Guid_Id
  FROM Table)
UPDATE t
  SET t.Integer_Id = c.RowOrderByGuid
FROM Table t
JOIN cte c ON t.Guid_Id = c.Guid_Id;

これで、Integer_Ids の順序が Guids の順序と一致するようになります。Guid 列を削除し、新しい Integer 列にクラスター化インデックスを追加しても、レコードの物理的な順序は保持されます。

答え2

定義上、クラスター化インデックスは実際のデータ ページに物理的な順序付けを強制します。そのため、クラスター化インデックスを削除して新しいインデックスを作成すると、データの物理的な順序付けが強制されます。

あなたの場合、次のようなことが起こると想定しても間違いないと思います。

  • 既存のクラスター化インデックスは削除されますが、ディスク上の実際のデータは移動されません。
  • 列の型を変更し (または既存の列を削除して新しい列を作成します)、その列が NULL 以外、一意、主キー、ID、自動増分になるように制約を設定します (これは重要です。そうしないと、SQL Server は列に何を入れればよいかわからないため、列を追加できません)。
  • この時点で、列はSQL Serverによって自動的に設定されます。ここで何が起こるかはわかりませんが、考える行がデータベースに物理的に格納される順序で入力されます。ただし、これは単なる推測です。
  • 問題は、UID が関係する場合、順序付けがかなり面倒になる可能性があることです。そのため、データが現在実際にどのように格納されているかはわかりませんし、後でどのように格納されるかもわかりません。列の配置に関する私の推測が正しければ、大規模な並べ替えは行われませんが、発生する可能性はあります。また、私の推測が正しかったとしても、テーブルが十分に大きい場合は、インデックスの構築にいずれにしても時間がかかります。

結論：あなた意思大きな影響を与え、あなたはできた順序付けされていない SELECT から、現在と同じ順序で行を取得します。試してみる必要があります。

答え3

クラスター化インデックスは、定義により、データの物理的な順序を決定するため、新しいクラスター化インデックスを作成すると、データの順序が変更されます。テーブルが大きい場合は、時間がかかることを想定してください。

答え4

クラスター化された主キーを持つテーブルを作成し、クラスター化された PK を削除した場合、テーブル内のデータの物理的な順序は変わりません。ただし、クエリ結果の物理的な順序がテーブル内の順序と同じであるとは限らないため、この順序付けはほとんど意味がありません。

次に整数列を追加し、その列にクラスター化された主キーを作成すると、テーブルはキーの並べ替え順序に再配置されます。キーの割り当て方法によっては、GUID と同じ物理的な順序になる場合とならない場合があります。GUID キーの並べ替え順序に基づいて明示的に割り当てることも (たとえば、古いキーの順序に対して row_number() を使用する)、他の方法で割り当てることもできます。順序が明示的に同じになるように手順を実行しない限り、テーブル内の行の物理的な順序が新しいキーの順序を決定することは保証されません。

関連情報