답변.

인덱스가 있는 뷰(Indexed View, 인덱스가 있는 물리적 뷰)는 클러스터형 고유 인덱스가 생성된 뷰(VIEW)입니다. 이를 통해 쿼리 결과를 디스크에 물리적으로 저장하고 인덱스를 사용하여 액세스를 가속화할 수 있습니다.

장점:

• 집계된 데이터나 자주 사용되는 데이터의 빠른 선택.
• 실시간 계산의 부하를 줄입니다.

제한 사항:

• 모든 유형의 쿼리가 지원되지 않습니다(예: TEXT, NTEXT, IMAGE 데이터 유형, 일부 함수는 사용할 수 없습니다).
• 기본 테이블의 변경 시 인덱스를 유지하기 위한 추가 비용 발생.
• 선언 시 엄격한 규칙 세트를 준수해야 합니다.

코드 예제

CREATE VIEW dbo.SalesSummary WITH SCHEMABINDING AS
   SELECT SalesPersonID, COUNT_BIG(*) AS SalesCount, SUM(TotalDue) AS TotalDue
   FROM dbo.Sales
   GROUP BY SalesPersonID;
GO
CREATE UNIQUE CLUSTERED INDEX idx_SalesSummary 
   ON dbo.SalesSummary (SalesPersonID);

복잡한 질문.

Q: 모든 뷰가 클러스터형 인덱스를 만들 수 있습니까?

A: 아니요, 인덱스는 제한 사항을 완전히 충족하는 뷰에 대해서만 만들 수 있습니다(예: 외부 참조가 없고, 집계 함수가 조화롭고 등). 그렇지 않으면 인덱스를 생성하는 쿼리가 오류를 발생시킵니다.

주제에 대한 미세한 점을 모르고 발생한 실제 오류 사례.

---

이야기

실제 은행 시스템 프로젝트에서 집계 보고서에 대한 선택 속도를 높일 필요가 있었습니다. 테이블 업데이트 시 부하 분석 없이 인덱스가 있는 뷰를 생성했습니다. 대량 삽입 작업 중 인덱스 업데이트에 상당한 비용이 들어 기본 테이블의 성능이 급락했습니다.

---

이야기

전문가가 외부 테이블과 JOIN을 지정한 뷰를 인덱싱할 수 있다고 잘못 생각했습니다. GETDATE() 함수가 포함된 인덱스 생성 요청은 "비결정론적 함수가 있는 뷰에 인덱스를 생성할 수 없습니다"라는 오류로 종료되었습니다. 아키텍처 수정을 위해 하루가 소요되었습니다.

---

이야기

대규모 전자 상거래 프로젝트에서 기본 테이블 "Products"의 데이터 업데이트가 차단을 초래했습니다. 이유는 많은 행을 집계하는 대형 인덱스가 있는 뷰로 인해 거래 관리를 잘못했기 때문입니다.