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

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

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

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

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

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

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

mysql optimization view

— 데이비드 르 바우어
소스

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

— FrustratedWithFormsDesigner

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

— David LeBauer

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

— FrustratedWithFormsDesigner

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

— Stephen Senkomago Musoke

답변:

MySQL은 뷰는 두 개의 서로 다른 알고리즘 중 하나를 사용하여 처리됩니다 MERGE나 TEMPTABLE. 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에는 적어도 파생 테이블에 인덱스를 추가하는 최적화가있는 것으로 보입니다.

— 데릭 다우니

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

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

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

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

— 레이니어 모 릴라
소스

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

— JHFB

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

— FrustratedWithFormsDesigner

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

— JHFB

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

— Rainier Morilla

@RainierMorilla Views는 성능을 떨어 뜨립니다 !! ??

— 수 하일 굽타

-2

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

— 샤 자드 샤이 크
소스

어떤 지점을 만들려고하는지 그리고 그것이 원래 게시물에 제시된 문제를 어떻게 해결하는지는 명확하지 않습니다. 질문을 다시 읽고 싶을 수도 있지만 어떤 경우에도 OP의 문제에 어떻게 적용 할 수 있는지 명확하게하기 위해 답을 확장하는 것을 고려하십시오.

— Andriy M