문제

다음과 같은 두 개의 테이블이 있다고 말합니다.

Employers (id, name, .... , deptId).
Depts(id, deptName, ...).

그러나 그 데이터는 그렇게 자주 수정되지 않을 것이며 나는 다음과 같은 쿼리를 원합니다.

SELECT name, deptName FROM Employers, Depts 
    WHERE deptId = Depts.id AND Employers.id="ID"

가능한 한 더 빨리하십시오.

내 머리에는 두 가지 가능한 해결책이 있습니다.

  • 테이블을 제거하십시오 :

    이 솔루션에도 불구하고 나는 "정규화 된 데이터베이스"의 큰 장점 중 일부를 잃을 것이지만 여기서는 성능이 필수입니다.

  • 해당 데이터에 대한보기를 작성하십시오.

    나는 데이터를 정규화하고 (여기 내 질문이 있습니다), 해당보기에 대한 쿼리의 성능은 그 관점없이 더 빠릅니다.

또는 같은 질문을하는 또 다른 방법으로,보기는 당신이 그것을 쿼리 할 때마다, 또는 dba에서보기가 어떻게 작동 하는가?.

도움이 되었습니까?

해결책

일반적으로 MS SQL Server와 같은 일부 소프트웨어의 옵션 인보기를 "구체화"하지 않는 한보기는 기본 테이블에 대한 쿼리로 변환되므로 원본보다 빠르거나 느리지 않습니다 (Minuscule 양의 마이너스 쿼리를 번역하는 데 시간이 걸리며, 실제로 쿼리를 실행하는 것과 비교할 수 없습니다).

성능 문제가 있다는 것을 어떻게 알 수 있습니까? 부하에서 프로파일 링하고 있습니까? 성능 병목 현상 이이 두 테이블인지 확인 했습니까? 일반적으로 하드 데이터가있을 때까지 성능 문제가 어디에서 왔는지 알지 못하고 올바른 것을 최적화하는 것을 알기 전까지는 최적화 할 시간을 소비하지 마십시오. 성능 문제의 80%는 20에서 나옵니다. 코드의 %.

다른 팁

Depts.ID가 해당 테이블의 주요 키이고 고용주를 색인하면이 쿼리는 수백만 건의 기록에 있어도 매우 빠르게 유지되어야합니다.

이 시나리오에서는 나에게 의미가 없습니다.

일반적으로,보기의 성능은 쿼리 자체를 실행할 때 성능과 거의 동일합니다. 보기의 장점은 단순히 쿼리를 추상화하는 것입니다. 그래서 당신은 그것에 대해 생각할 필요가 없습니다.

구체화 된보기 (또는 일부 사람들이 말한 것처럼 "스냅 샷")를 사용할 수 있지만, 데이터는 최신 새로 고침만큼 최근에있을 것입니다.

답변 중 하나에 대한 의견에서,이 질문의 저자는 그가 MySQL에서 구체화 된 견해를 만들 수있는 방법을 찾고 있다고 설명합니다.

MySQL은 다른 DBMSE와 같이 구체화 된 뷰의 개념을 멋진 패키지로 래핑하지는 않지만 하나를 만드는 데 필요한 모든 도구가 있습니다.

당신이해야 할 일은 이것입니다 :

  1. 쿼리 결과의 초기 구체화를 만듭니다.
  2. 새로 삽입 된 고용주와 일치하는 모든 행을 구체화 된 테이블에 삽입하는 고용주 테이블에 인서트에 트리거를 만듭니다.
  3. 구체화 된 테이블에서 해당 행을 삭제하는 고용주 테이블에서 삭제 트리거를 만듭니다.
  4. 구체화 된 테이블의 해당 행을 업데이트하는 고용주 테이블의 업데이트 트리거를 만듭니다.
  5. 부서 테이블에 대해서도 동일합니다.

기본 테이블이 자주 업데이트되지 않으면 괜찮을 수 있습니다. 그러나이 작업을 수행하면 추가 생성/업데이트/삭제 비용을 알고 있어야합니다. 또한 속임수에 대해 모르는 일부 DBA가 시간이 오면 트리거를 마이그링하지 않고 데이터베이스를 마이그레이션하지 않도록하고 싶을 것입니다. 그러니 잘 문서화하십시오.

분명하고 현재의 문제라는 것을 알지 않는 한 조기 최적화처럼 들립니다.

MySQL은 뷰를 실현하지 않으며 기본 테이블에 대한 쿼리보다 빠르지 않습니다. 또한, 어떤 경우에는 덜 최적화되어 느리게 느려집니다.

그러나 견해는 또한 쿼리가 실제보다 덜 복잡하다고 상상하기 위해 미래에 코드를 유지하는 개발자의 "숨기기"를 "숨기기"합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top