질의의 설명 계획을 어떻게 해석합니까?

질의의 설명 계획을 어떻게 해석합니까?

SQL 문이 어떻게 실행되고 있는지 이해하려고 할 때 설명 계획을 살펴보는 것이 권장될 수 있습니다.설명 계획을 해석할 때 어떤 과정을 거쳐야 합니까?'아, 이거 잘 되는구나'와 '아, 그건 아니야'는 두각을 나타내야 할 부분이다.

풀 테이블스캔이 나쁘고 인덱스 접근성이 좋다는 댓글을 볼 때마다 몸서리가 쳐집니다.전체 테이블 스캔, 인덱스 범위 스캔, 고속 전체 인덱스 스캔, 중첩 루프, 병합 조인, 해시 조인 등은 의미 있는 결론에 도달하기 위해 분석가가 이해해야 하는 단순한 액세스 메커니즘입니다.

풀스캔은 데이터 세그먼트(테이블 또는 테이블(서브) 파티션)의 블록의 대부분을 읽는 가장 효율적인 방법이며, 종종 성능 문제를 나타낼 수 있지만, 이는 쿼리의 목표를 달성하기 위한 효율적인 메커니즘인지 여부에 대한 컨텍스트에 불과합니다.데이터 웨어하우스 및 BI 전문가로서 성능의 가장 중요한 경고 플래그는 인덱스 기반 액세스 방식과 중첩 루프입니다.

따라서 설명 플랜을 읽는 방법에 대해서는 Oracle 매뉴얼을 참조해 주십시오.http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

퍼포먼스 튜닝 가이드도 잘 읽어주세요.

또, 「카디날리티 피드백」의 구글을 가지는 것, 즉, 설명 플랜을 이용해, 쿼리의 다양한 스테이지에서의 카디날리티의 추정치를 실행중에 실제로 경험한 키나리티와 비교할 수 있는 기술.볼프강 브레이틀링이 그 방법의 저자인 것 같다.

결론은 액세스 메커니즘을 이해하는 것입니다.데이터베이스를 이해합니다.쿼리의 의도를 이해합니다.경험의 법칙을 피하세요.

이 주제는 너무 커서 이런 질문에는 대답할 수 없다.Oracle의 Performance Tuning Guide를 읽어보시기 바랍니다.

다음 두 가지 예는 INDEX를 사용한 전체 스캔과 FAST 스캔을 보여 줍니다.

비용과 카디널리티에 집중하는 것이 가장 좋습니다.예를 들어 인덱스를 사용하면 쿼리 실행 비용이 절감됩니다.

좀 더 복잡하지만(그리고 100%의 처리능력은 없습니다), 기본적으로 비용은 CPU와 IO 비용의 함수이며, Cardinality는 Oracle이 해석할 것으로 예상되는 행의 수입니다.둘 다 줄이는 것은 좋은 일입니다.

쿼리 비용은 쿼리 및 Oracle 옵티마이저 모델(예: COST, CHOICE 등)과 통계 실행 빈도에 따라 영향을 받을 수 있습니다.

예 1:

스캔 http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

예 2: 인덱스를 사용한 경우:

색인 http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

그리고 이미 제안했듯이 TABLE SCAN에 주의하십시오.일반적으로는 피할 수 있습니다.

연속 스캔 같은 걸 찾는 게 도움이 될 수도 있지만, 현실은 숫자에 있어...그냥 어림짐작일 때 빼고요!일반적으로 쿼리 계획을 살펴보는 것보다 훨씬 유용한 것은 실제 실행을 살펴보는 것입니다.Postgres에서는 EXPLY와 EXPLY ANALYZE의 차이점이며, EXPLYE ANALYZE는 실제로 쿼리를 실행하여 각 노드에 대한 실제 타이밍 정보를 가져옵니다.그러면 플래너가 생각하는 것보다 실제로 무슨 일이 일어나고 있는지 알 수 있습니다.대부분의 경우 순차 검색은 전혀 문제가 되지 않고 쿼리에서 다른 문제가 됩니다.

다른 하나는 실제 비용이 많이 드는 단계를 식별하는 것입니다.많은 그래픽 툴에서는 다양한 크기의 화살표를 사용하여 계획의 다양한 부분에 비용이 얼마나 드는지 나타냅니다.이 경우, 얇은 화살표가 들어오고 굵은 화살표가 나가는 단계만 찾습니다.GUI 를 사용하지 않는 경우는, 그 수치를 주시해, 어느 쪽이 갑자기 큰지를 조사할 필요가 있습니다.연습을 조금만 하면 문제 영역을 쉽게 찾을 수 있습니다.

이러한 문제에 대해서는 ASKTOM을 사용하는 것이 가장 좋습니다.특히 이 질문에 대한 그의 답변에는 온라인 Oracle 문서에 대한 링크가 포함되어 있으며, 이 문서에는 이러한 많은 규칙이 설명되어 있습니다.

한 가지 명심해야 할 것은 계획을 설명하는 것이 정말 최선의 추측이라는 것입니다.

sqlplus 사용법을 배우고 AUTOTRACE 명령을 사용해 보는 것이 좋습니다.몇 가지 확실한 수치가 있으면 일반적으로 더 나은 결정을 내릴 수 있습니다.

하지만 넌 ASKTOM을 해야 해.그는 그것에 대해 모든 것을 알고 있다:)

설명의 출력에 각 단계가 얼마나 걸렸는지 알 수 있습니다.첫 번째는 오랜 시간이 걸렸던 단계를 찾아서 그 의미를 이해하는 것입니다.순차 검사와 같은 작업을 통해 보다 나은 인덱스가 필요하다는 것을 알 수 있습니다. 대부분 특정 데이터베이스와 경험에 대한 조사입니다.

"아뇨, 그렇지 않아요"는 종종 테이블 스캔의 형태입니다.테이블 스캔은 특별한 인덱스를 사용하지 않으며 메모리 캐시에 있는 모든 유용한 인덱스를 삭제하는 데 도움이 될 수 있습니다.포스트그레어 중예를 들어 SQL은 다음과 같습니다.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

예를 들어 인덱스를 사용하여 행을 쿼리하는 것이 이상적일 수 있습니다.하지만 이것은 당신이 찾고 있는 것 같은 빨간 깃발 패턴 중 하나입니다.

기본적으로 각 조작을 살펴보고 조작이 어떻게 기능해야 하는지 알고 있는 상태에서 조작이 "이치에 맞는"지 확인합니다.

예를 들어, A와 B의 두 테이블을 각각 열 C와 D(A)에 결합하는 경우입니다.C=B.D)를 사용하면 계획에서 테이블 A에 클러스터화된 인덱스 스캔(SQL Server 용어 -- Oracle 용어 확실하지 않음)을 표시한 다음 테이블 B에 있는 일련의 클러스터된 인덱스 검색에 대한 중첩 루프 조인이 문제가 있다고 생각할 수 있습니다.이 시나리오에서는 엔진이 조인된 열의 인덱스에 대한 인덱스 스캔 쌍과 병합 조인을 차례로 수행할 것으로 예상할 수 있습니다.추가 조사를 통해 옵티마이저가 해당 결합 패턴 또는 실제로 존재하지 않는 인덱스를 선택하도록 하는 잘못된 통계가 드러날 수 있습니다.

계획의 각 서브섹션에서 소요된 시간의 비율을 살펴보고 엔진이 무엇을 하는지 고려합니다.예를 들어 테이블을 스캔하는 경우 스캔 중인 필드에 인덱스를 붙이는 것을 고려합니다.

주로 인덱스 스캔이나 테이블 스캔을 찾습니다.일반적으로 where 문 또는 join 문에 있는 중요한 열에 대한 인덱스가 누락되었음을 나타냅니다.

http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx 에서 :

실행 계획에서 다음 중 하나가 발견되면 해당 경고 표시를 고려하여 잠재적인 성능 문제를 조사해야 합니다.퍼포먼스 측면에서는 각각 이상적이지 않습니다.

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

이러한 문제를 피할 수 있는 것은 아니지만 피할 수 있는 횟수가 많을수록 쿼리 성능이 빨라집니다.

경험칙

(상세도 읽어보실 수 있습니다.

• Oracle 문서
• 아스크토
• SQL Server 문서
  )

나빠

여러 큰 테이블의 테이블스캔

좋아요.

고유 색인 사용
색인에 모든 필수 필드가 포함됩니다.

가장 일반적인 장점

지금까지 본 약 90%의 성능 문제 중 가장 쉬운 것은 로트(4개 이상)의 테이블을 가진 쿼리를 2개의 작은 쿼리와 임시 테이블로 분할하는 것입니다.

언급URL : https://stackoverflow.com/questions/79266/how-do-you-interpret-a-querys-explain-plan