A.1-2 (DB2) Operations
use-the-index-luke 저자 Markus Winand
Markus Winand는 SQL에 대한 통찰력을 제공하고 다양한 시스템이 SQL을 지원하는 방법을 modern-sql.com 에서 보여줍니다. 이전에 그는 use-the-index-luke.com 을 만들었는데, 지금도 활발하게 유지되고 있습니다. Markus는 winand.at 를 통해 강사, 연사 및 컨설턴트로 고용될 수 있습니다.
You can upload a Korean translation of use-the-index-luke.com on your blog
Thank you from the bottom of my heart to author Makus Winand for allowing me.
These are translations that I use for studying by using a papago (google translate)
The translations may not be correct or there may be a typo.
I'd appreciate it if you could point it out in the comments.
use-the-index-luke.com 의 한글번역본을 블로그에 업로드 해도 된다고
허락해주신 Makus Winand 저자님께 진심으로 감사합니다.
이 번역본들은 제가 공부용도로 번역기(papago, google transrate)를 돌려서
번역한 내용들이라 맞지 않거나, 오타가 있을수 있습니다.
댓글로 지적해주시면 감사하겠습니다.
https://use-the-index-luke.com/sql/explain-plan/db2/operations
ㄴDB2 LUW Execution Plan Operations
가장 일반적인 DB2 LUW 실행 계획 작업에 대한 간단한 참조입니다. IBM 설명서에서 전체 목록을 찾습니다.
Index and Table Access
IXSCAN은 B-tree traversal를 수행하고 리프 노드 체인을 따라 일치하는 모든 항목을 찾습니다. 1장 "Anatomy of an SQL Index"도 참조하십시오.
이른바 index filter predicates vmdkSARG" predicates)는 종종 IXSCAN의 성능 문제를 야기합니다. 다음 섹션에서는 이러한 항목을 식별하는 방법을 설명합니다. Oracle의 INDEX ... SCAN 작업 제품군과 유사합니다.
START 및 STOP 술어가 없으면 전체 인덱스 검색을 나타냅니다.
last_explained 보기는 괄호 안의 역방향 스캔을 나타냅니다(예: IXSCAN(REVERSE)).
이전 인덱스 조회에서 검색된 RID를 사용하여 테이블에서 행을 검색합니다. 1장 "SQL 인덱스의 해부학"도 참조하십시오. Oracle의 TABLE ACCESS BY INDEX ROWID와 유사합니다.
이를 전체 테이블 검색이라고도 합니다. 디스크에 저장된 전체 테이블(모든 행 및 열)을 읽습니다. 다중 블록 읽기 작업이 전체 테이블 검색 속도를 크게 향상시키지만 여전히 가장 비용이 많이 드는 작업 중 하나입니다. 높은 IO 속도 외에도 전체 테이블 검색은 상당한 양의 CPU 시간을 소비할 수 있도록 모든 테이블 행을 검사해야 합니다. "전체 테이블 스캔"도 참조하십시오.
이 작업은 인덱스 병합에 사용되며 정렬된 데이터 페이지를 미리 가져오는 경우가 더 많습니다.
Joins
일반적으로 조인 작업은 한 번에 두 개의 테이블만 처리합니다. 쿼리에 조인이 더 많은 경우, 조인은 순차적으로 실행됩니다. 처음 두 테이블, 다음 테이블의 중간 결과입니다. 따라서 조인의 맥락에서 "테이블"이라는 용어는 "중간 결과"를 의미할 수도 있습니다.
한 테이블에서 결과를 가져오고 첫 번째 테이블에서 각 행에 대한 다른 테이블을 쿼리하여 두 테이블을 조인합니다.
“Nested Loops” 도 참조하십시오.
해시 조인은 조인의 한 쪽에서 후보 레코드를 해시 테이블로 로드한 다음 조인의 다른 쪽에서 각 행을 검색합니다. “Hash Join”을 참조하십시오.
병합 조인은 두 개의 정렬된 목록을 지퍼처럼 결합합니다. 접합부의 양쪽을 모두 보호해야 합니다.
“Sort Merge”도 참조하십시오.
ZZJOIN
스타 스키마를 사용하는 데이터 웨어하우스를 위한
다중 테이블 조인(두 개 이상)입니다.
Sorting and Grouping
절별 순서에 따라 결과를 정렬합니다. 이 작업은 파이프라인이 아닌 중간 결과를 구현하기 위해 많은 양의 메모리가 필요합니다. 이 작업은 MSJOIN 또는 GRPBY 작업에 필요한 순서를 설정하는 데도 사용됩니다. 또한 SORT는 별도의 작업을 위해 중복된 행을 제거할 수 있습니다.
“Indexing Order By”을 참조하십시오.
last_explained 뷰는 괄호(예: SORT(UNIQUE))에서 고유가 수행되는지 여부를 나타냅니다. 상위 N 정렬에는 TOP-N 레이블이 지정됩니다(예: because of fetch first ... rows only).
미리 정렬된 집합에서 행을 중복 제거합니다. SORT 작업 없이 필요한 순서를 설정할 수 있는 경우 구별하기 위해 사용됩니다(예: IXSCAN이 필요한 순서로 전달하므로). SORT 작업이 필요한 경우 SORT 작업 자체가 중복 제거를 수행합
절별 그룹에 따라 집합을 집계합니다. 이 작업은 정렬/그룹별 알고리즘 또는 해시 기반 접근 방식(v10.1 이후)을 사용하여 실행할 수 있습니다. 색인화 그룹 기준을 참조하십시오.
last_explained 보기는 괄호 안의 집계 모드를 나타냅니다
(예: GRPBY(HASH COMPLETE).
Top-N Queries
DB2 LUW에는 fetch first...와 같은 상위 N절과 직접 관련된 실행 계획 작업이 없습니다... 행만. 그러나 SORT가 수행되는 경우 last_explained 보기는 괄호 안의 상위 N 최적화를 나타냅니다(예: SORT(TOP-N)).
SORT 작업이 필요하지 않은 경우 실행 계획에 상위 N 동작의 가시적인 표시가 없습니다. 그러나 술어가 없는 상태에서 비용 값이 갑자기 떨어지거나 행 수 추정치가 떨어지면 작업 중에 상위 N 절이 있어야 한다는 것을 알 수 있습니다.