MySql 표시 성능

MySql 표시 성능

닫혔어. 이 질문은 좀 더 자세히 설명해야 합니다.초점을 맞춥니다.현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 하나의 문제에 초점을 맞추도록 질문을 업데이트하십시오.

7년 전에 문을 닫았어요

이 질문을 개선하다

뷰 사용의 길을 걷는다면, 어떻게 하면 좋은 퍼포먼스를 보장할 수 있을까요?

아니면 애초에 뷰를 사용하지 않고 선택한 문장에 동등한 내용을 포함시키는 것이 더 나을까요?

사정에 따라 다르겠지.

그것은 당신이 보는 것에 전적으로 달려있다.그러나 대부분의 경우 노력을 줄이고 더 높은 성능을 제공합니다.SQL 문이 색인화되지 않은 뷰를 참조하는 경우 파서와 쿼리 최적화 도구는 SQL 문과 뷰의 소스를 모두 분석한 후 단일 실행 계획으로 해결합니다.SQL 문에 대한 하나의 계획과 뷰에 대한 별도의 계획은 없습니다.

뷰는 컴파일되지 않습니다.다른 테이블로 구성된 가상 테이블입니다.작성 시 서버상의 어딘가에 존재하지 않습니다.뷰를 구성하는 기본 쿼리는 쿼리 최적화 도구와 동일한 성능 게인 또는 Ding의 영향을 받습니다.뷰와 뷰의 기본 쿼리에서 성능을 테스트한 적은 없지만 성능은 약간 다를 수 있습니다.데이터가 비교적 정적인 경우 인덱싱된 보기에서 더 나은 성능을 얻을 수 있습니다.이것은, 「컴파일」이라고 하는 관점에서 생각하고 있는 것일지도 모릅니다.

뷰의 장점:

1. 데이터를 개체에 저장하지 않고 볼 수 있습니다.
2. 표의 보기를 제한합니다. 즉, 표의 일부 열을 숨길 수 있습니다.
3. 두 개 이상의 테이블을 결합하여 사용자에게 하나의 개체로 표시합니다.
4. 테이블에 행을 삽입할 수 없도록 테이블의 접근을 제한합니다.

다음의 편리한 링크를 참조해 주세요.

1. VIEW 퍼포먼스와SQL 문
2. 뷰가 단순한 쿼리보다 빠릅니까?
3. Mysql VIEWS vs. PHP 쿼리
4. MySql View는 동적이고 효율적입니까?
5. 구체화된 뷰와표:어떤 장점이 있습니까?
6. 뷰에 대한 쿼리는 SQL을 직접 실행하는 것보다 느립니까?
7. TEMPTABLE 뷰의 성능 문제에 대한 해결 방법
8. SQL Server에서 인덱스 뷰를 사용하여 성능 향상

여기 tl;dr 요약이 있습니다. Peter Zaitsev와 다른 곳에서 자세한 평가를 찾을 수 있습니다.

MySQL의 뷰는 일반적으로 좋지 않습니다.Groubeshark에서는 유해하다고 간주하여 항상 회피하고 있습니다.주의를 기울이면 작동시킬 수 있지만, 데이터를 선택하는 방법을 기억하거나 복잡한 조인을 다시 입력할 필요가 없도록 하는 것이 좋습니다.최악의 경우 엄청난 비효율성, 복잡성 숨기기, 우발적으로 중첩된 하위 선택(일시 테이블 필요 및 디스크 스레싱 발생) 등이 발생할 수 있습니다.

그냥 회피하고 질문을 암호로 하는 것이 가장 좋습니다.

Peter Zaitsev의 블로그가 대부분의 세부사항을 가지고 있다고 생각한다.개인적인 경험의 관점에서 말하는 것은 일반적으로 단순하게만 유지하면 더 잘 수행될 수 있습니다.내 고객 중 한 명이 계속 한 뷰를 다른 뷰 위에 겹쳐서 퍼포먼스 악몽을 꾸게 되었습니다.

일반적으로 뷰는 테이블의 다른 면을 보여주기 위해 사용합니다.예를 들어, 내 직원 표에서 관리자를 표시하거나 급여 필드를 비 HR 직원으로부터 숨깁니다.또한 MySQL 내에서 정확히 무슨 일이 일어나고 있는지 이해하기 위해 쿼리 및 뷰에서 항상 EXPLINE을 실행해야 합니다.

당신의 시나리오에서 확실한 증거를 원한다면, 나는 당신이 테스트하는 것을 제안합니다.뷰를 사용하는 것이 항상 퍼포먼스 킬러라고는 말할 수 없지만, 다시 한번 나쁘게 쓰여진 뷰는 퍼포먼스를 저하시킬 가능성이 있습니다.

목적은 충족되지만, 일반적으로는 복잡성과 비효율성이 보다 직접적인 접근보다 더 중요합니다.이전에 두 뷰에서 결합되어 결과를 정렬하는 SQL 문을 접한 적이 있습니다.뷰도 정렬되어 있기 때문에 실행 시간은 몇 시간 정도로 측정될 수 있었습니다.

지금까지는 언급되지 않았지만 뷰의 소스 테이블을 충분히 인덱싱할 수 있다는 점이 큰 차이를 보이고 있습니다.

위에서 설명한 바와 같이 보기는 DB에 상주하지 않고 매번 재구성됩니다.따라서 DB를 쉽게 재구성할 수 있는 모든 것이 보기 성능을 향상시킵니다.

대부분의 경우 뷰는 스토리지에는 매우 좋지 않지만(일반 형식이 아님), 이후 사용(분석 수행, 사용자에게 데이터 표시 등)에는 매우 좋은 방식으로 데이터를 결합하고 서로 다른 테이블의 데이터를 집계합니다.

작업이 수행되는 열이 인덱싱되는지 여부에 따라 뷰 성능에 큰 차이가 있습니다.테이블 및 관련 열이 이미 인덱싱된 경우 뷰에 액세스하는 것이 먼저 인덱스를 반복적으로 재계산하는 것으로 끝나지 않습니다.(단점으로는 소스 테이블에서 데이터가 조작되었을 때)

CREATE VIEW 스테이트먼트의 JOINS 및 GROUP BY 절에서 사용되는 모든 열을 색인화합니다.

뷰의 퍼포먼스 효과가 아니라 뷰를 사용하는 경우, 퍼포먼스를 확보할 수 있는 방법에 대해 논의한다면 (자신과 마찬가지로) 억제라고 생각합니다.

모든 경우에 쿼리를 단순하게 하기 위해 뷰를 작성하기만 하면 큰 문제가 발생할 수 있습니다.그러나 뷰가 실제로 퍼포먼스 면에서 완전히 사용되도록 주의하지 마십시오.최종적으로 실행하는 모든 쿼리는 정상적으로 실행되어야 합니다(@eggyal 링크의 코멘트 예 참조).물론 그건 동어법이지만, 따라서 가치가 떨어지지는 않는다.

특히 뷰에서 뷰를 작성하지 않도록 주의할 필요가 있습니다.그렇게 하면 뷰를 작성하기가 쉬워질 수 있기 때문입니다.

마지막으로 뷰를 사용하는 이유를 확인해야 합니다.프로그래밍 측에서의 생활을 쉽게 하기 위해 이 작업을 수행할 때마다 저장 프로시저 IMHO를 사용하는 것이 좋습니다.

상황을 통제하기 위해 특정 뷰를 가진 이유를 적어두고 사용 이유를 결정할 수 있습니다.프로그래밍 내에서 '새로운' 용도로 사용할 때마다 뷰가 실제로 필요한지, 왜 필요한지, 그리고 이것이 여전히 정상적인 실행 경로를 제공하는지 다시 확인하십시오.사용 방법을 계속 확인하여 빠른 속도로 유지하십시오. 그리고 해당 보기가 정말 필요한지 계속 확인하십시오.

언급URL : https://stackoverflow.com/questions/10302615/mysql-views-performance