MySQL에서 언제 뷰를 사용해야합니까?


54

분석에 사용하기 위해 여러 조인에서 테이블을 만들 때 새 테이블을 만드는 것보다 뷰를 사용하는 것이 더 좋은 방법은 언제입니까?

뷰를 사용하는 것을 선호하는 한 가지 이유는 데이터베이스 스키마가 관리자가 Ruby 내에서 개발했기 때문에 Ruby에 익숙하지 않기 때문입니다. 테이블을 만들도록 요청할 수 있지만 추가 단계가 필요하며 새 조인을 개발 / 테스트 할 때 더 많은 유연성을 원합니다.

SO에 대한 관련 질문에 대한 답변에 따라 뷰를 사용하기 시작했습니다 ( R을 사용할 때, SQL을 사용할 때 ). 최고 투표 응답은 "데이터가 단일 테이블에있을 때까지 SQL에서 데이터 조작을 수행 한 다음 R에서 나머지를 수행합니다."

뷰를 사용하기 시작했지만 뷰에 몇 가지 문제가 있습니다.

  1. 쿼리가 훨씬 느리다
  2. 뷰는 분석에서 사용하는 프로덕션 데이터베이스에서 백업 데이터베이스로 덤프되지 않습니다.

이 용도에 적합한 뷰가 있습니까? 그렇다면 성능 저하가 예상됩니까? 뷰에서 쿼리 속도를 높이는 방법이 있습니까?


뷰가 적절한 것처럼 들리지만 쿼리 할 때 속도 저하의 원인이 무엇인지 잘 모르겠습니다.
FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner 도움이 될만한 진단이 있습니까? 동일한 복잡한 쿼리는 조인 된 테이블에서 직접 수행 될 때 <4 초가 걸리고 뷰에서 수행 될 때> 25가 걸립니다. 조회수에 성능 불이익이 없을 것으로 예상됩니까?
David LeBauer

MySQL을 사용한 지 오래되어 실제로 말할 수 없습니다.
FrustratedWithFormsDesigner

나는 MySQL을 사용하고 100K 이상에 도달하면 뷰가 끔찍하고 쓸모 없다고 말할 것입니다. 반환 할 필드와 사용할 조인을 제어 할 수있는 직선 쿼리를 사용하십시오.
Stephen Senkomago Musoke

답변:


43

MySQL은 뷰는 두 개의 서로 다른 알고리즘 중 하나를 사용하여 처리됩니다 MERGETEMPTABLE. MERGE적절한 별칭이있는 검색어 확장입니다. TEMPTABLEWHERE 절을 실행하기 전에 뷰가 결과를 임시 테이블에 넣고 인덱스가없는 것처럼 보입니다.

'third'옵션은입니다 UNDEFINED. 이것은 MySQL에게 적절한 알고리즘을 선택하도록 지시합니다. MySQL MERGE은 더 효율적이기 때문에 사용하려고 시도합니다 . 주요주의 사항 :

MERGE 알고리즘을 사용할 수없는 경우 임시 테이블을 대신 사용해야합니다. 뷰에 다음 구문이 포함되어 있으면 MERGE를 사용할 수 없습니다.

  • 집계 함수 (SUM (), MIN (), MAX (), COUNT () 등)

  • 뚜렷한

  • GROUP BY

  • HAVING

  • 한도

  • UNION 또는 UNION ALL

  • 선택 목록의 하위 쿼리

  • 리터럴 값만 참조합니다 (이 경우 기본 테이블이 없음).

[src]

귀하의 VIEWS가 TEMPTABLE 알고리즘을 요구하여 성능 문제를 일으키는 것으로 추측합니다.

다음은 MySQL의 뷰 성능에 대한 오래된 블로그 게시물 이며 더 좋아 보이지는 않습니다.

그러나 인덱스를 포함하지 않는 임시 테이블 (전체 테이블 스캔을 야기 함)의이 문제에 대해서는 터널 끝에서 약간의 빛이있을 수 있습니다. 에서 5.6 :

FROM 절의 서브 쿼리에 구체화가 필요한 경우 옵티마이 저는 구체화 된 테이블에 인덱스를 추가하여 결과에 대한 액세스 속도를 높일 수 있습니다. ... 인덱스를 추가 한 후 옵티마이 저는 구체화 된 파생 테이블을 인덱스가있는 일반 테이블과 동일하게 처리 할 수 ​​있으며 생성 된 인덱스의 이점과 유사합니다. 인덱스가없는 쿼리 실행 비용과 비교하여 인덱스 생성 오버 헤드는 무시할 수 있습니다.

@ypercube가 지적한 것처럼 MariaDB 5.3도 동일한 최적화를 추가했습니다. 이 기사 에는 프로세스에 대한 흥미로운 개요가 있습니다.

최적화가 적용된 다음 파생 테이블을 상위 SELECT에 병합 할 수 없습니다. 파생 테이블이 병합 가능한 VIEW에 대한 기준을 충족하지 않을 때 발생합니다.


나는 이러한 주장에 대한 테스트를 수행하지 않았지만 MariaDB 5.3 (최근에 안정적으로 출시됨)은 뷰를 포함하여 옵티 마이저에서 몇 가지 주요 개선 사항을 가지고 있습니다 .Fields of merge-able views and derived tables are involved now in all optimizations employing equalities
ypercubeᵀᴹ

@ypercube 해당 링크에 감사드립니다 ... MySQL 5.6에는 적어도 파생 테이블에 인덱스를 추가하는 최적화가있는 것으로 보입니다.
데릭 다우니

14

뷰는 보안 도구입니다. 특정 사용자 나 응용 프로그램이 데이터 테이블의 위치를 ​​알지 못하게하려면 필요한 열만있는보기를 제공하십시오.

뷰는 항상 성능을 저하 시키므로 유사한 쿼리는 뷰가 아닌 저장 프로 시저 및 함수 여야합니다.

쿼리 튜닝을 수행하려면 항상 모범 사례를 따르고 WHERE 절에서 함수를 사용하지 말고 인덱스를 작성하여 선택 속도를 높이십시오. 그러나 인덱스를 남용하지 않으면 인서트, 업데이트 및 삭제 성능이 저하됩니다.

도움이되는 유용한 문서가 있습니다. http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234


5
뷰가 보안 도구라는 데 동의하지 않습니다. 이러한 방식으로 사용할 수 있지만 보고서 개발자가 정기적으로 사용하는 쿼리의 복잡성을 제거하기 위해이를 사용합니다.
JHFB

2
@ JHFB : 나는 당신에게 동의하지만 어쩌면 그것이 성능이 불이익을받는 것처럼 들리는 MySQL에서 작동하는 방식일까요?
FrustratedWithFormsDesigner

@frustratedwithformsdesigner 요점-MySQL을 사용한 지 오래되었습니다.
JHFB

1
MySQL의 @ JHFB보기는 큰 문제입니다! mysqlperformanceblog.com/2007/08/12/…
Rainier Morilla

2
@RainierMorilla Views는 성능을 떨어 뜨립니다 !! ??
수 하일 굽타

-2

뷰는 여러 테이블 쿼리에서 극복하기 위해 테이블을 하나로 병합하기 위해 미리 정의 된 구조 (데이터 없음)라고 생각합니다.이 테이블은 빠른 관계형 쿼리를 위해 실제 데이터에서 사용할 수 있습니다 ...


2
어떤 지점을 만들려고하는지 그리고 그것이 원래 게시물에 제시된 문제를 어떻게 해결하는지는 명확하지 않습니다. 질문을 다시 읽고 싶을 수도 있지만 어떤 경우에도 OP의 문제에 어떻게 적용 할 수 있는지 명확하게하기 위해 답을 확장하는 것을 고려하십시오.
Andriy M
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.