답변:
그렇습니다 . 뷰에는 클러스터형 인덱스가 할당 될 수 있으며, 그럴 경우 결과 쿼리 속도를 높일 수있는 임시 결과를 저장합니다.
업데이트 : 적어도 세 사람이 이것에 대해 투표했습니다. 모든 것을 존중하면서, 나는 그들이 틀렸다고 생각합니다. Microsoft의 자체 문서를 통해 Views는 성능을 향상시킬 수 있습니다.
첫째, 간단한보기가 제자리에 확장되어 성능 향상에 직접적으로 기여하지는 않습니다. 그러나 인덱싱 된 뷰는 성능을 크게 향상시킬 수 있습니다 .
문서로 직접 이동하겠습니다.
뷰에 고유 한 클러스터형 인덱스가 생성되면 뷰의 결과 집합이 즉시 구체화되어 데이터베이스의 실제 저장소에 유지되므로 실행 시간에 비용이 많이 드는 작업을 수행하는 오버 헤드가 줄어 듭니다.
둘째, 이러한 인덱싱 된 뷰는 최적화 프로그램이 적절한 경우 테이블 참조 대신 뷰를 사용 하므로 다른 쿼리에서 직접 참조하지 않는 경우에도 작동 할 수 있습니다 .
다시, 문서 :
인덱스 된 뷰는 두 가지 방법으로 쿼리 실행에 사용될 수 있습니다. 쿼리는 인덱싱 된 뷰를 직접 참조하거나보다 중요하게는 쿼리 최적화 프로그램이 가장 저렴한 쿼리 계획에서 뷰를 일부 또는 모든 쿼리로 대체 할 수 있다고 판단되면 뷰를 선택할 수 있습니다. 두 번째 경우 기본 테이블과 일반 인덱스 대신 인덱싱 된 뷰가 사용됩니다. 쿼리 최적화 프로그램이 쿼리를 실행하는 동안 뷰를 사용하기 위해 쿼리에서 뷰를 참조 할 필요는 없습니다. 이를 통해 기존 응용 프로그램은 해당 응용 프로그램을 변경하지 않고 새로 작성된 인덱싱 된 뷰를 활용할 수 있습니다.
이 문서와 성능 향상을 보여주는 차트는 여기 에서 찾을 수 있습니다 .
업데이트 2 : 답변은 "보기"가 아니라 성능상의 이점을 제공하는 "인덱스"에 기초하여 비판되었습니다. 그러나 이것은 쉽게 반박됩니다.
우리가 소규모 국가의 소프트웨어 회사라고 가정 해 봅시다. 리투아니아를 예로 들어 보겠습니다. 전 세계적으로 소프트웨어를 판매하고 레코드를 SQL Server 데이터베이스에 보관합니다. 우리는 매우 성공적이므로 몇 년 안에 1,000,000 개 이상의 기록을 보유하고 있습니다. 그러나 종종 세금 목적으로 판매를보고해야하며 본국에서는 소프트웨어 사본 100 개만 판매 한 것으로 나타났습니다. 리투아니아어 레코드에 대한 인덱싱 된 뷰를 만들면 MS 설명서에 설명 된대로 필요한 레코드를 인덱싱 된 캐시에 보관할 수 있습니다. 2008 년 리투아니아 판매에 대한 보고서를 실행할 때 쿼리는 깊이가 7 (일부 미사용 잎이있는 Log2 (100)) 인 인덱스를 검색합니다. VIEW없이 동일한 작업을 수행하고 인덱스를 테이블에 의존하기 만하면 검색 깊이가 21 인 인덱스 트리를 탐색해야합니다!
분명히 View 자체는 인덱스 만 사용하는 것보다 성능 이점 (3 배)을 제공합니다. 실제 사례를 사용하려고했지만 간단한 리투아니아 판매 목록을 통해 더 큰 이점을 얻을 수 있습니다.
내 예제에는 직선 b- 트리를 사용하고 있습니다. SQL Server가 b- 트리의 일부 변형을 사용한다고 확신하지만 세부 정보는 알 수 없습니다. 그럼에도 불구하고 요점은 중요하다.
업데이트 3 : 인덱싱 된 뷰가 기본 테이블에 배치 된 인덱스 만 사용하는지에 대한 질문이 제기되었습니다. 즉, "인덱싱 된 뷰는 표준 인덱스와 동일하며 뷰에 새롭거나 고유 한 것을 제공하지 않습니다." 이것이 사실이라면 위의 분석은 정확하지 않습니다! 이 비판이 유효하지 않다고 생각하는 이유를 설명하는 Microsoft 문서의 인용문을 제공하겠습니다.
쿼리 성능을 향상시키기 위해 인덱스를 사용하는 것은 새로운 개념이 아닙니다. 그러나 인덱싱 된 뷰는 표준 인덱스로는 얻을 수없는 추가 성능 이점을 제공합니다.
물리적 스토리지의 데이터 지속성에 대한 위의 인용문과 뷰에서 인덱스가 작성되는 방법에 대한 문서의 기타 정보와 함께 인덱싱 된 뷰는 캐시 된 SQL 선택 이 아니라고 말하는 것이 안전하다고 생각합니다 . 기본 테이블에 정의 된 인덱스. 따라서 저는이 답변을 계속지지합니다.
일반적으로 말해서 뷰는 주로 편의성과 보안을 위해 사용되며 그 자체로는 속도 이점이 없습니다.
즉, SQL Server 2000 이상 에는 몇 가지 경고와 함께 성능을 크게 향상시킬 수있는 인덱싱 된 뷰 라는 기능 이 있습니다 .
COUNT, MIN, MAX, 또는 TOP.이 기사에서는 인덱싱 된 뷰의 추가 이점과 제한 사항에 대해 설명 합니다 .
당신은 할 수 ...
- 뷰 정의는 동일한 데이터베이스에서 하나 이상의 테이블을 참조 할 수 있습니다.
- 고유 클러스터형 인덱스가 생성되면 뷰에 대해 클러스터되지 않은 추가 인덱스를 생성 할 수 있습니다.
- 삽입, 업데이트, 삭제 및 절단을 포함하여 기본 테이블의 데이터를 업데이트 할 수 있습니다.
당신은 할 수 없습니다 ...
- 뷰 정의는 다른 뷰나 다른 데이터베이스의 테이블을 참조 할 수 없습니다.
- COUNT, MIN, MAX, TOP, 외부 조인 또는 다른 키워드 나 요소를 포함 할 수 없습니다.
- 기본 테이블 및 열을 수정할 수 없습니다. WITH SCHEMABINDING 옵션으로 뷰가 작성됩니다.
- 쿼리 최적화 프로그램이 수행 할 작업을 항상 예측할 수는 없습니다. Enterprise Edition을 사용하는 경우 고유 클러스터형 인덱스를 쿼리 옵션으로 자동 고려하지만 "더 나은"인덱스를 찾으면 사용됩니다. 최적화 프로그램이 WITH NOEXPAND 힌트를 통해 인덱스를 사용하도록 강요 할 수 있지만 힌트를 사용할 때는주의해야합니다.
SQL Server에서 쿼리 계획은 쿼리 /보기 매개 변수를 기반으로 뷰와 일반 SQL 쿼리 모두에 대해 계획 캐시에 저장됩니다. 두 경우 모두, 오랫동안 사용하지 않았을 때 캐시에서 삭제되며 새로 제출 된 다른 쿼리에 공간이 필요합니다. 그런 다음 동일한 쿼리가 발행되면 다시 컴파일되고 계획이 다시 캐시에 저장됩니다. 따라서 동일한 SQL 쿼리와 동일한 뷰를 동일한 빈도로 재사용한다는 점에서 차이는 없습니다.
분명히, 일반적으로보기는 본질적으로 (누군가 그것을보기에 충분할 정도로 자주 사용되어야한다고 생각 했음) 일반적으로 임의의 SQL 문보다 "재사용"될 가능성이 높습니다.
편집 : 내가 틀렸다, 당신은 위의 마크 답변을 볼 수 있습니다 .
SQL Server 에 대한 경험으로는 말할 수 없지만 대부분의 데이터베이스의 경우 대답은 아니요입니다. 보기를 사용하면 성능 측면에서 얻을 수있는 유일한 이점은 쿼리를 기반으로 일부 액세스 경로를 만들 수 있다는 것입니다. 그러나 뷰를 사용하는 주된 이유는 쿼리를 단순화하거나 테이블의 일부 데이터에 액세스하는 방법을 표준화하기위한 것입니다. 일반적으로 말하면 성능상의 이점은 없습니다. 그래도 틀렸을 수도 있습니다.
나는 약간 더 복잡한 예를 생각해보고 스스로 볼 시간이다.
구체화 된 뷰를 작성하면 ( 스키마 바인딩 사용 ) 더 빠를 수 있습니다 . 구체화되지 않은 뷰는 일반 쿼리처럼 실행됩니다.
SQL Server가 실행 계획을 저장 한 다음 즉시 파악하려고하는 대신 사용하기 때문에 뷰가 더 빠르다는 것을 이해합니다. 요즘의 성능 향상은 아마도 예전만큼 크지 않을 것이라고 생각하지만보기를 사용하기 위해 약간의 개선이있을 것이라고 추측해야합니다.
확실히 뷰는 SQL Server의 중첩 쿼리보다 낫습니다. 왜 Mark Brittingham의 게시물을 읽을 때까지 더 나은지 정확히 알지 못했지만 뷰와 중첩 쿼리를 사용할 때 몇 가지 테스트를 실행하고 거의 충격적인 성능 향상을 경험했습니다. 각 버전의 쿼리를 한 번에 수백 번 실행 한 후 쿼리의 뷰 버전이 절반으로 완료되었습니다. 나는 그것이 충분한 증거라고 말하고 싶습니다.
두 쿼리가 동일하게 수행 될 것으로 기대합니다. 뷰는 저장된 쿼리 정의에 지나지 않으며 뷰에 대한 데이터 캐싱 또는 저장은 없습니다. 옵티마이 저는 첫 번째 쿼리를 실행할 때 두 번째 쿼리로 효과적으로 전환합니다.
실질적인 차이가 없으며 BOL을 읽으면 평범한 이전 SQL SELECT * FROM X가 계획 캐싱 등을 활용한다는 것을 알 수 있습니다.
뷰의 목적은 쿼리를 반복해서 사용하는 것입니다. 이를 위해 SQL Server, Oracle 등은 일반적으로 뷰의 "캐시 된"또는 "컴파일 된"버전을 제공하여 성능을 향상시킵니다. 일반적으로이 방법은 "간단한"쿼리보다 성능이 뛰어나지 만 쿼리가 실제로 매우 단순하면 이점이 무시 될 수 있습니다.
이제 복잡한 쿼리를 수행하는 경우보기를 작성하십시오.
필자가 찾은 결과보기를 사용하는 것이 일반 쿼리보다 약간 빠릅니다. 내 저장 프로 시저 는 약 25 분이 걸리고 (다른 더 큰 레코드 세트 및 여러 조인으로 작업) 뷰를 사용한 후 (클러스터되지 않은) 성능은 조금 빨랐지만 전혀 중요하지 않았습니다. 나는 다른 쿼리 최적화 기술 / 방법을 사용하여 극적인 변화를 만들어야했습니다.
보기 또는 테이블에서 선택하면 의미가 없습니다.
물론 뷰에 불필요한 조인, 필드 등이없는 경우 뷰 성능을 향상시키는 데 사용되는 쿼리, 조인 및 인덱스의 실행 계획을 확인할 수 있습니다.
더 빠른 검색 요구 사항을 위해보기에서 색인을 작성할 수도 있습니다. http://technet.microsoft.com/en-us/library/cc917715.aspx
그러나 '% ... %'와 같이 검색하는 경우 SQL 엔진보다 텍스트 열의 인덱스가 도움이되지 않습니다. 사용자가 '... %'와 같은 검색을 수행하도록 강요하면 그보다 빠릅니다.
ASP 포럼에서 답변 참조 : https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+
모든 기대에 반하여, 어떤 상황에서는 견해가 더 느립니다.
최근에 Oracle에서 가져온 데이터에 다른 형식으로 마사지 해야하는 데 문제가있을 때 이것을 발견했습니다. 20k 개의 소스 행일 수 있습니다. 작은 테이블. 이를 위해 오라클 데이터를 테이블로 가져올 수있는 그대로 변경 한 다음 뷰를 사용하여 데이터를 추출했습니다. 우리는 그러한 견해에 근거한 2 차 견해를 가지고있었습니다. 어쩌면 3-4 수준의 전망 일 수 있습니다.
200 개의 행을 추출한 최종 쿼리 중 하나가 45 분 이상 걸립니다. 이 쿼리는 일련의 뷰를 기반으로합니다. 어쩌면 3-4 레벨 깊이.
문제의 각 뷰를 가져 와서 하나의 중첩 된 쿼리에 sql을 삽입하고 몇 초 안에 실행할 수 있습니다.
심지어 각 뷰를 임시 테이블에 작성하고 뷰 대신 쿼리를 쿼리 할 수 있으며 단순히 중첩 뷰를 사용하는 것보다 훨씬 빠릅니다.
더 이상한 점은 데이터베이스로 가져 오는 소스 행의 한계에 도달 할 때까지 성능이 좋았다는 것입니다. 며칠 동안 공간에서 절벽을 떨어 뜨 렸습니다. 소스 행이 몇 개 더 필요했습니다.
따라서 뷰에서 가져온 쿼리를 사용하는 것은 중첩 된 쿼리보다 훨씬 느리므로 나에게 의미가 없습니다.
이 스레드를 가로 질러 가용성 그룹을 사용할 때 고려해야 할 사항으로 Brent Ozar 의이 게시물을 공유하고 싶었습니다.