クラスタ化されたインデックス作成は今や必須です-なぜですか？

以前は、クラスター化インデックスを（常に）エンゲージする/回避するかどうかについての議論/ディスカッションは決定的ではありませんでした。

まあ、私はそれらが時々適切な特定の目的とコンテキストで使用されることを理解しました。

SQL Azureデータベースのクラスター化インデックスの要件：

「SQL Azureはクラスター化インデックスのないテーブルをサポートしていません。テーブルにはクラスター化インデックスが必要です。クラスター化制約なしでテーブルを作成する場合、テーブルで挿入操作を許可する前にクラスター化インデックスを作成する必要があります。」

以前の結論、根拠、および説明には適合しません。

例外なくクラスタ化インデックスのユビキタス性を厳密に課すという、これまでの説明から逃した理論的根拠は何ですか？

SQL Azureの内部を読む：

SQL Azureは、アプリケーションデータストレージ用の論理データベースを提供します。実際には、各サブスクライバーのデータは実際には複数回保存され、単一のデータセンター内の3つの物理サーバーに分散された3つのSQL Serverデータベースに複製されます。多くのサブスクライバーが同じ物理データベースを共有する場合があります。

データの3つのレプリカを同期させるには、クラスター化されたキーが必要です。キーなしでは、どの行が更新されたかを知ることは不可能です。ヒープ（クラスター化インデックスのないテーブル）には物理的な「キー」（fileid：pageid：slot）のみがあり、論理データベースの3つのレプリカが物理データベースを他の論理データベースと共有しているため、あるサーバーの物理アドレスは他のサーバーでは意味がありませんレプリカ、したがってヒープはおそらく複製できませんでした。

Azureは、リモートサーバー上の分散型クラウドベースシステムです。データは複数のドライブ/サーバーに格納される可能性が高く、ヒープ上でこれを実行することは非常に非効率的です（システムがチェックするマシンを知る必要があるため、クラスター化インデックスがないと、これはリソース集約的な操作です）。 。

クラスター化インデックスは、テーブルのすべての行と他のすべてのインデックスのルックアップを提供するため、azureでのすべての操作がなければ、複数のマシンでテーブルスキャンが行われます。