데이터베이스보기가 쿼리 성능에 영향을 줍니까?

Question

데이터베이스보기는 데이터 액세스를 단순화하는 방법 일 뿐이며보기에 기반한 쿼리를 실행하는 것과 달리보기에 액세스 할 때 성능상의 이점을 제공합니까? 뷰가 뷰 데이터의 각 쿼리에 저장된 뷰 쿼리를 추가하는 것과 기능적으로 동일하다는 의심이 들면이 올바른지 아니면 다른 세부 정보 및/또는 최적화가 발생 했습니까?

Answer 1

RDBMS에 따라 다르지만 대개 최적화가 진행되지 않고 쿼리를 단순화하는 편리한 방법 일뿐입니다. 그러나 일부 데이터베이스 시스템에서는 캐싱 메커니즘을 사용하는 "materialized view"를 사용합니다.

Answer 2

일반적으로보기는 자주 필요한 결과 집합을 정의하기위한 공통된 속기를 만드는 방법 일뿐입니다.

그러나 단점이 있습니다. 유혹은 언제든지보기를 사용하고 싶을 때마다 필요할 것이라고 생각하는 모든 열을 추가하는 것입니다. YAGNI가 위반되었습니다. 열뿐만 아니라 때로는 추가 외부 조인이 "경우에 따라"고정됩니다. 따라서 인덱스를 덮는 것이 더 이상 포함되지 않을 수 있으며 쿼리 계획의 복잡성이 증가하고 효율성이 떨어질 수 있습니다.

YAGNI는 SQL 디자인에서 중요한 개념입니다.

Answer 3

필자는 Views를 항상 읽기 전용 저장 프로 시저와 같은 것으로 간주했습니다. 가능한 한 미리 컴파일 할 수 있도록 미리 데이터베이스에 많은 정보를 제공하십시오.

뷰를 인덱싱하여 실행중인 쿼리 유형에 대한 최적의 데이터보기에 액세스 할 수 있습니다.

Answer 4

일반적으로 뷰는 기본 테이블에 직접 작성된 쿼리와 동등하게 수행되어야합니다.

하지만 가장자리가있을 수 있으며 코드를 테스트해야합니다. 현대의 모든 RDBMS 시스템에는 쿼리 계획을보고 실행을 모니터링 할 수있는 도구가 있습니다. 결정적인 데이터를 손끝에서 찾을 수있을 때 내 (또는 다른 사람의) 단어를 사용하지 마십시오.

Answer 5

뷰 외부에서 실행중인 특정 쿼리와 뷰 외부에서 실행되는 동일한 쿼리가 동등하게 수행되어야하지만 두 뷰를 함께 조인해야하는 경우 상황이 훨씬 더 복잡해집니다. 필요하지 않은 테이블을 쿼리로 가져 오거나 중복 된 테이블을 가져 오면 쉽게 끝낼 수 있습니다. 데이터베이스의 옵티마이 저는 좋은 쿼리 실행 계획을 만드는 데 어려움이있을 수 있습니다. 따라서 뷰는보다 세분화 된 보안 등을 허용하는면에서 매우 뛰어날 수 있지만 모듈성에는 반드시 좋은 것은 아닙니다.

Answer 6

나는 이것이 오래된 스레드라는 것을 알고있다. 토론은 훌륭하지만 한 가지 더 생각하고 싶습니다. 성능은 또한 데이터를 가져 오기 위해 사용하는 항목에 따라 다릅니다. 예를 들어 Microsoft Access와 같은 프론트 엔드를 사용하는 경우보기를 사용하여 복잡한 쿼리의 성능을 확실히 높일 수 있습니다. 이는 Access가 항상 우리가 원하는대로 SQL 서버를 끌어 당기는 것은 아니기 때문에 - 전체 테이블을 가로 질러 거기에서 로컬로 처리하려고 시도하는 경우도 있습니다! 보기를 사용하는 경우에는 그렇지 않습니다.

Answer 7

그렇습니다. 모든 현대 RDBMS (2005 년 이후 MSSQL 등) 뷰의 쿼리 계획이 캐시되어 쿼리를 계획하고 인라인으로 수행되는 동일한 SQL에 비해 성능이 빨라지는 오버 헤드가 제거됩니다. 이전에는 (그리고 매개 변수화 된 SQL/Prepared Statements에도 적용됩니다.) 사람들은 올바르게 저장 프로 시저가 더 잘 수행되었다고 생각했습니다.

많은 사람들이 여전히 오늘 이것을보고 현대 신화를 만듭니다. Views/PS에는 SP의 캐시 된 쿼리 계획이 있기 때문에 평소와 다름 없었습니다.