1.3 Slow Indexes, Part I
---------------------------------------------
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/anatomy/slow-indexes
느린 인덱스 Part I
Tree Travelsal의 효율성에도 불구하고 인덱스 조회가 기대만큼 빠르게 작동하지 않는 경우가 있습니다. 이 모순은 오랫동안 "퇴보된 인덱스"의 미신을 부채질 해왔다.
그 미신은 index rebuild를 기적의 해결책으로 선언한다.
(https://use-the-index-luke.com/sql/myth-directory)
(부록 B, "미신 디렉토리 " 에서는 이 미신과 다른 미신에 대해 자세히 설명합니다.)
지금은 인덱스를 재구축해도 장기적으로 성능이 향상되지 않는 것을 당연하게 생각할 수 있습니다. 인덱스를 사용하는 경우에도 사소한 문장이 느릴수 있는 진짜 이유는 앞의 항을 바탕으로 설명할 수 있습니다.
느린 인덱스 lookup의 첫번째 요소는 리프 노드 체인 입니다. 그림 1.3의 '57'에 대한 검색을 다시 검토합니다. 인덱스에 일치하는 엔트리가 두 개 있습니다.
적어도 2개의 엔트리는 동일하며, 보다 정확하게 말하면 다음 리프 노드는 "57"에 대한 추가 엔트리를 가질 수 있습니다. 데이터베이스는 일치하는 엔트리가 더 있는지 확인하기 위해 다음 리프 노드를 읽어야 합니다. 즉, 인덱스 룩업은 Tree travelsal을 수행해야 할 뿐만 아니라 리프 노드 체인을 따라야 합니다.
느린 인덱스 lookup의 두 번째 요소는 테이블에 액세스하는 것입니다. 단일 리프 노드에도 다수의 히트(대개 수백 개)가 포함될 수 있습니다. 해당하는 테이블 데이터는 일반적으로 여러 테이블 블록에 분산되어 있습니다.
(그림 1.1 "인덱스 리프 노드 및 해당 테이블 데이터 " 참조). 즉, 각 히트마다 추가 테이블 액세스 권한이 있습니다.
인덱스 룩업에는 (1) 트리 트래버설 (2) 리프노드 체인을 따르는 (3) 테이블 데이터를 가져오는 세 가지 단계가 필요합니다. 트리 트래버설은 액세스된 블록 수 상환(인덱스깊이)이 있는 유일한 단계입니다. 다른 두 단계에서는 많은 블록에 액세스해야 할 수 있습니다. 이러한 절차로 인해 인덱스 검색이 느려집니다.
"저속 인덱스" 미신의 기원은 인덱스 lookup이 트리를 통과할 뿐이라고 잘못 믿고 있기 때문에 느린 인덱스는 "끊어진" 트리 또는 "불균형" 트리로 인해 발생되어야 한다는 것입니다.
실제로 대부분의 데이터베이스에 인덱스를 어떻게 사용하는지 물어볼 수 있습니다.
Oracle 데이터베이스는 이 점에서 다소 상세하며 기본 인덱스 lookup을 설명하는 세 가지 다른 작업이 있습니다.
인덱스 UNIQUE SCAN
그 INDEX UNIQUE SCAN는 Tree travelsal만 수행합니다. Oracle 데이터베이스는 고유한 제약 조건으로 인해 검색 기준이 하나 이상의 항목과 일치하지 않는 경우 이 작업을 사용합니다.
인덱스 RANGE 스캔
그 INDEX RANGE SCAN는 Tree travelsal을 실행하고 리프 노드체인을 따라 일치하는 모든 엔트리를 검색합니다. 이것은 여러 엔트리가 검색 기준에 일치할 가능성이 있는 경우의
fallback operation 입니다.
인덱스 ROWID에 의한 테이블 액세스
TABLE ACCESS BY INDEX ROWID operation 은 테이블에서 행을 가져옵니다. 이 작업은 이전 인덱스 스캔 작업에서 일치하는 모든 레코드에 대해 종종 수행됩니다.
중요한 건 … INDEX RANGE SCAN는 잠재적으로 인덱스의 대부분을 읽을 수 있습니다. 각 행에 대한 대한 테이블 액세스 권한이 하나 더 있는 경우 INDEX을 사용하더라도 쿼리가 느려질 수 있습니다.