MySql은 성능을 봅니다.

MySql은 성능을 봅니다.

---

뷰를 사용하는 길을 가고 있다면 어떻게 좋은 성능을 보장 할 수 있습니까?

아니면 처음부터 뷰를 사용하지 않고 동등한 것을 select 문에 통합하는 것이 더 낫습니까?

---

때에 따라 다르지.

그것은 당신이보기를 통해보고있는 것에 전적으로 달려 있습니다. 그러나 아마도 노력을 줄이고 더 높은 성능을 제공 할 것입니다. SQL 문이 인덱싱되지 않은 뷰를 참조하면 파서 및 쿼리 최적화 프로그램은 SQL 문과 뷰의 소스를 분석 한 다음 단일 실행 계획으로 확인합니다. SQL 문에 대한 하나의 계획과보기에 대한 별도의 계획이 없습니다.

뷰는 컴파일되지 않습니다 . 다른 테이블로 구성된 가상 테이블입니다. 만들 때 서버 어딘가에 상주하지 않습니다. 뷰를 구성하는 기본 쿼리는 쿼리 최적화 프로그램과 동일한 성능 향상 또는 땡의 영향을받습니다. 뷰 대 기본 쿼리에서 성능을 테스트 한 적이 없지만 성능이 약간 다를 수 있다고 생각합니다. 데이터가 상대적으로 정적 인 경우 인덱싱 된 뷰에서 더 나은 성능을 얻을 수 있습니다. 이것은 아마도 "컴파일 된"관점에서 생각하고있는 것일 수 있습니다.

보기의 장점 :

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

다음 유용한 링크를 참조하십시오.

1. VIEW 대 SQL 문의 성능
2. 보기가 단순 쿼리보다 빠릅니까?
3. MySQL VIEWS 대 PHP 쿼리
4. MySql 뷰는 동적이며 효율적입니까?
5. 구체화 된 뷰와 테이블 비교 : 장점은 무엇입니까?
6. 뷰를 통한 쿼리가 SQL을 직접 실행하는 것보다 느립니까?
7. TEMPTABLE보기의 성능 문제에 대한 해결 방법
8. SQL Server에서 인덱싱 된 뷰를 사용하여 성능 향상 확인

---

나는 Peter Zaitsev의 블로그에 대부분의 세부 사항이 있다고 생각합니다. 일반적으로 단순하게 유지하면 개인적인 경험 관점에서 말하는 것이 잘 수행 될 수 있습니다. 내 고객 중 한 명은 한 뷰를 다른 뷰 위에 계속 쌓았고 결국 성능이 악몽에 빠졌습니다.

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

시나리오에서 확실한 증거를 원한다면 테스트하는 것이 좋습니다. 뷰를 사용하는 것이 항상 성능 킬러라고 말하기는 정말 어렵고 잘못 작성된 뷰는 아마도 성능을 떨어 뜨릴 것입니다.

---

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

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

이를 피하고 쿼리를 코드로 유지하는 것이 가장 좋습니다.

---

그들은 그들의 목적에 부합하지만 숨겨진 복잡성과 비 효율성은 일반적으로보다 직접적인 접근 방식보다 중요합니다. 두 개의 뷰를 결합하고 결과를 정렬하는 SQL 문을 발견 한 적이 있습니다. 뷰도 정렬되어 있으므로 실행 시간을 몇 시간으로 측정 할 수있었습니다.

---

일반적으로 뷰의 성능 효과가 아니라 "뷰를 사용하는 경우 성능을 보장하는 방법"에 대해 논의하고 있다면 (자신과 마찬가지로) 제한으로 귀결되는 것이라고 생각합니다.

모든 경우에 쿼리를 간단하게 만들기 위해 뷰를 작성하기 만하면 큰 문제가 발생할 수 있지만 뷰가 실제로 성능면에서 유용하다는 점에주의하지 마십시오. 결국 수행하는 모든 쿼리는 정상적으로 실행되어야합니다 (@eggyal의 해당 링크에서 주석 예제 참조). 물론 그것은 팽팽하지만 덜 가치있는 것은 아닙니다.

보기를 더 쉽게 만들 수 있기 때문에 특히보기에서보기를 만들지 않도록주의해야합니다.

결국 뷰를 사용하는 이유를 살펴 봐야합니다. 프로그래밍 끝에서 삶을 더 쉽게 만들기 위해이 작업을 수행 할 때마다 저장 프로 시저 IMHO를 사용하는 것이 더 나을 수 있습니다.

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

---

지금까지 언급되지 않았지만 큰 차이를 만드는 것은 뷰의 소스 테이블을 적절히 인덱싱하는 것입니다 .

위에서 언급 한 바와 같이, 전망은 DB에 거주하지 않는 만 있습니다 때마다 다시 . 따라서 DB에 대한 재 구축을 더 쉽게 만드는 모든 것은 뷰의 성능을 향상시킵니다.

종종 뷰는 저장에는 매우 좋지 않지만 (정상적인 형식이 아님) 추가 사용 (분석 수행, 사용자에게 데이터 제공 등)에는 매우 좋은 방식으로 데이터를 결합하고 다른 테이블의 데이터를 결합하고 집계합니다.

작업이 수행 된 열이 인덱싱되었는지 여부는 뷰의 성능에 큰 차이를 만듭니다. 테이블과 관련 열이 이미 인덱싱 된 경우 뷰에 액세스하는 것은 인덱스를 반복해서 다시 계산하는 것으로 끝나지 않습니다 . (단점은 소스 테이블에서 데이터를 조작 할 때 수행됩니다.)

! CREATE VIEW 문의 JOINS 및 GROUP BY 절에 사용 된 모든 열을 인덱싱하십시오!

참고 URL : https://stackoverflow.com/questions/10302615/mysql-views-performance