클러스터형 인덱싱이 이제 필요합니다-왜?

이전에는 클러스터형 인덱스를 사용 / 사용하지 않을지에 대한 토론 / 토론이 결정적이지 않았습니다.

글쎄, 나는 그것들이 때때로 적절한 + 특정 목적과 맥락으로 사용되어야한다는 것을 이해했다.

SQL Azure 데이터베이스 클러스터형 인덱스 요구 사항 :

"SQL Azure는 클러스터형 인덱스가없는 테이블을 지원하지 않습니다. 테이블에는 클러스터형 인덱스가 있어야합니다. 클러스터 된 제약 조건없이 테이블을 만들면 테이블에서 삽입 작업을 허용하기 전에 클러스터형 인덱스를 만들어야합니다."

이전 결론, 근거 및 설명에는 적합하지 않습니다.

예외없이 클러스터 된 인덱스의 유비쿼터스를 강요 적으로 부과한다는 이전 설명에서 놓친 근거는 무엇입니까?

SQL Azure 내부 읽기 :

SQL Azure는 응용 프로그램 데이터 저장소를위한 논리 데이터베이스를 제공합니다. 실제로 각 가입자의 데이터는 실제로 여러 번 저장되며 단일 데이터 센터에서 3 개의 물리적 서버에 분산 된 3 개의 SQL Server 데이터베이스에 복제됩니다. 많은 가입자가 동일한 물리적 데이터베이스를 공유 할 수 있습니다.

데이터의 세 복제본을 동기화 상태로 유지하려면 클러스터 된 키가 필요합니다. W / oa 키, 어떤 행이 업데이트되었는지 알 수 없습니다. 힙 (클러스터형 인덱스가없는 테이블)에는 물리적 '키'(fileid : pageid : slot) 만 있으며 논리적 데이터베이스의 3 개의 복제본이 다른 논리적 데이터베이스와 물리적 데이터베이스 를 공유 하므로 한 서버의 물리적 주소는 다른 서버에서 의미가 없습니다. 따라서 복제본을 힙을 복제 할 수 없습니다.

Azure는 원격 서버의 분산 클라우드 기반 시스템입니다. 데이터는 여러 드라이브 / 서버에 저장 될 가능성이 높으며 힙에서이를 수행하는 것이 매우 비효율적입니다 (시스템이 점검 할 머신을 알아야하고 클러스터 된 인덱스가 없으면 자원 집약적 인 작업입니다) .

클러스터형 인덱스는 테이블의 모든 행과 다른 모든 인덱스에 대한 조회를 제공하므로, Azure에서 모든 작업을 수행하지 않으면 여러 시스템에서 테이블 스캔이 수행됩니다.