SQL Server 초점 제거 분석(북 마크 조회,RID 조회,키 조회)
앞의 몇 절 은 모두 기본 적 인 내용 입 니 다.본 절 에서 우 리 는 색인 성능 의 최적화 에 대해 이야기 합 니 다.빅 데 이 터 를 처리 할 때 먼저 생각 나 는 것 은 색인 입 니 다.이런 문제 에 부 딪 히 면 바 쁘 고 각종 자 료 를 조사 하 는데 왜 평소에 기본 적 인 공 을 세우 지 않 습 니까?우 리 는 얕 은 것 에서 깊 은 것 으로,짧 은 내용 으로 깊이 이해 합 니 다.올 라 오 자마자 문 제 를 틀 어 죽 이 는 것 이 아 닙 니 다.즉시 해결 방안 을 제시 하고 문 제 를 던 지고 문 제 를 해결 할 때 까지 당신 은 GET 를 했 습 니까?
북 마크 조회,RID 조회,키 조회 정의
이 세 가 지 를 말 하면 색인 에 대한 연구 가 깊 지 않 은 어린이 신발 이 멍청 하고 무엇 인지 우 리 는 먼저 위의 세 가 지 를 라벨 찾기,줄 ID 찾기,키 찾기 로 번역 합 니 다.탭 찾기 와 키 찾기 는 SQL 2005 이전에 Key Lookup 이라는 뜻 입 니 다.어떻게 설명 하고 어떻게 정의 합 니까?먼저 우 리 는 정 의 를 보지 않 고 다음 단계 의 해석 을 직접 봅 니 다.만약 에 당신 이 정말 참 지 못 한다 면 원우[영 홍]의 견 해 를 보 세 요.해석 은 아직도 매우 적절 합 니 다.우 리 는 이 세 가지 개념 을 간략하게 설명 한다.
검색 에서 저 희 는 되 돌아 오 는 열 에 대해 검색 조건 에서 비 집합 색인 을 만 들 었 다 면 비 집합 색인 을 사용 하여 찾 으 려 고 시도 할 수 있 습 니 다.되 돌아 오 는 열 에 비 집합 색인 을 만 들 지 않 았 다 면 데이터 페이지 로 돌아 가 이 열 들 의 데 이 터 를 가 져 옵 니 다.표 에 집합 색인 이 존재 하거나 없 더 라 도 표 에 되 돌아 가 거나 집합 색인 에 데 이 터 를 가 져 옵 니 다.상기 장면 설명 에 대해 표 에 집합 색인 을 만 들 지 않 으 면 Bookmar Lookup 이 라 고 합 니 다.표 에 집합 색인 이 없 지만 비 집합 색인 이 존재 한다 면 RID Lookup 이 라 고 합 니 다.여기 서 우 리 는 이렇게 시간 이 걸 리 고 기본 표 로 돌아 가 데 이 터 를 얻 으 려 고 생각 하기 때문에 이 절 에서 상기 세 가 지 를 제거 하여 조회 성능 을 향상 시 킬 수 있 습 니 다.이제 우리 함께 보 자.
북 마크 룩 업,RID 룩 업,키 룩 업 문 제 를 던 집 니 다.
우 리 는 먼저 아래 표를 만 듭 니 다.
USE TSQL2012
GO
CREATE TABLE Sales.Orders
(
[orderid] INT,
[shipaddress] VARCHAR(100),
[shipcity] VARCHAR(100),
[shipregion] VARCHAR(100))
GO
이어서 조 회 를 진행 하 다
USE TSQL2012
GO
SELECT orderid, shipaddress, shipregion
FROM Sales.Orders
WHERE shipcity = ' '
이것 은 더 이상 말 할 필요 가 없습니다.색인 을 추가 하지 않 았 습 니 다.검색 계획 을 실행 하 는 것 은 전체 표 스 캔 입 니 다.다음은 orderid 에 집합 색인 을 만 듭 니 다.다음 과 같 습 니 다.
CREATE CLUSTERED INDEX idx_cls_orderid ON Sales.Orders(orderid)
우 리 는 상술 한 조 회 를 다시 집행 한다.이때 우 리 는 집합 색인 을 만 들 었 기 때문에 이때 집합 색인 을 조회 합 니 다.여기 서 우 리 는 상황 이 전체 표 스 캔 에서 색인 스 캔 으로 바 뀌 는 것 을 보 았 습 니 다.우 리 는 조회 할 때 줄곧 조회 조건 을 가 져 왔 지만 조회 조건 에 대해 우 리 는 어떠한 조작 도 하지 않 았 다.만약 우리 가 이때 조회 조건 에 색인 을 만 들 었 다 면 조회 의 성능 은 또 약간의 개선 을 얻 었 을 것 이다.우 리 는 검색 조건 에 대해 비 집합 색인 을 만 들 기 시작 했다.
CREATE NONCLUSTERED INDEX idx_nc_shipcity ON Sales.Orders(shipcity)
우 리 는 다시 이어서 조 회 를 집행 한다.검색 조건 에 대해 비 집합 색인 을 만 드 는 것 을 관찰 하 였 습 니 다.검색 계획 은 비 집합 색인 을 사용 하여 결 과 를 찾 을 것 입 니 다.그러나 ship address,shipcity,shipregion 은 색인 의 일부분 이 아 닙 니 다.이 때 검색 엔진 은 기본 표 로 돌아 가 이 데 이 터 를 얻 고 돌아 갑 니 다.이런 행 위 를 북 마크 룩 업 이나 키 룩 업 이 라 고 한다.다음은 본문 제목 과 같은 문제 가 발생 하여 문 제 를 해결 하고 북 마크 룩 업 이나 키 룩 업 을 제거 합 니 다.우 리 는 두 가지 다른 방법 으로 해결 하려 고 시도 했다.
북 마크 룩 업,RID 룩 업,키 룩 업 문제 해결
비 집합 인덱스 덮어 쓰기 인덱스 만 들 기
우 리 는 검색 조건 과 검색 열 에 대해 비 집합 색인 을 만 듭 니 다.
CREATE NONCLUSTERED INDEX idx_all_cover ON Sales.Orders(shipaddress,orderid,shipcity,shipregion)
이때 우 리 는 검색 열 에 비 집합 색인 을 만 들 었 습 니 다.이 때 는 데이터 페이지 에서 데 이 터 를 가 져 오지 않 고 색인 에서 직접 돌아 올 것 입 니 다.그래서 여기까지 우 리 는 Key Lookup 을 제거 한 셈 입 니 다.그러나 이때 또 다른 문제 가 발생 했 습 니 다.검색 계획 을 실행 하 는 것 은 색인 검색 입 니 다.색인 은 도대체 무엇 입 니까?예 를 들 어 하나의 색인 은 데이터베이스 에 있 는 책 에서 시 작 된 색인 과 같 습 니 다.우 리 는 책 에서 우리 가 필요 로 하 는 데 이 터 를 빨리 찾 아야 합 니 다.이때 책 은 바로 우리 가 말 한 표 입 니 다.색인 스 캔 은 표 의 모든 줄 을 읽 고 조건 을 만족 시 키 는 모든 데 이 터 를 되 돌려 주 는 것 을 의미 합 니 다.색인 스 캔 을 실행 할 때 모든 줄 의 잎 노드 에 있 는 모든 줄 이 스 캔 됩 니 다.이것 은 색인 에 있 는 모든 줄 이 직접 검색 표 가 아니 라 검색 표 와 비교 하면 표 스 캔 은 표 의 데 이 터 를 직접 읽 는 것 을 의미 합 니 다.따라서 표 스 캔 과 색인 스 캔 은 조금 다 릅 니 다.색인 검색 은 색인 페이지 데이터 에 의존 하여 조건 을 만족 시 키 는 모든 줄 을 찾 습 니 다.색인 검색 은 조건 을 만족 시 키 고 페이지 에 이러한 만족 조건 을 포함 하 는 줄 에 만 영향 을 주기 때문에 색인 검색 이 더욱 효율 적 입 니 다.
상기 에서 우 리 는 색인 검색 과 색인 검색 을 조금 설명 하 였 는데,상술 한 문 제 는 우리 가 비 집합 색인 을 만 들 었 다 는 것 이다.그러나 결과 에 실 행 된 검색 계획 은 색인 검색 이 고,매우 궁금 하 다.색인 소 백 을 막 배 운 나 에 게 어떻게 해 야 할 지 모 르 겠 고,저장 을 늦 추 는 것 이 라 고 생각 하여 각종 캐 시 를 제거 하 는 것 이 모두 좋 지 않다.그래서 검색 열 에 있 는 데이터 가 NULL 에 의 한 것 인지,검색 열 데이터 가 중복 되 어 발생 한 것 인지,몇 번 도 시도 하지 않 았 는데,결국 어떤 것 이 잘 되 었 다 는 것 을 알 게 되 었 다.아래 와 같다
CREATE NONCLUSTERED INDEX idx_cls_cover ON
Sales.Orders(shipcity,orderid,shipaddress,shipregion)
이때 만약 우리 가 조회 조건 을 아래 와 같이 수정 할 것 이다.
USE TSQL2012
GO
SELECT orderid, shipaddress, shipregion
FROM Sales.Orders
WHERE shipaddress = ' '
GO
여기에서 우 리 는 유일한 차이 점 은 우리 가 비 집합 색인 을 만 들 때의 순서 와 조회 조건 이 다 르 면 색인 검색 과 색인 검색 의 전환 을 초래 할 수 있다 는 것 을 발견 해 야 한다.그러면 도대체 언제 색인 검색 을 실행 할 수 있 을 까?우 리 는 다음 과 같은 일반적인 총 결 을 진행 할 수 있다.
색인 찾기 의 일반적인 결론:조건 에 WHERE 나 ON 이 포함 되 어 있 으 면 검색 조건 은 색인 집합 열 에서 첫 번 째 여야 합 니 다.이 때 색인 찾기 는 사 용 됩 니 다.
이 때 우 리 는 약간의 내용 을 삽입 합 니 다.위 에서 우 리 는 덮어 쓰기 색인 을 만 들 었 습 니 다.우 리 는 덮어 쓰기 색인 과 기본 상황 에서 색인 을 모 아 찾 는 성능 비용 을 비교 합 니 다.
덮어 쓰기 인덱스 와 기본 집합 인덱스 성능 비용 비교
FROM Sales.Orders WITH(INDEX([PK_Orders]))
WHERE orderid<11072
go
SELECT orderid, shipaddress, shipregion
FROM Sales.Orders WITH(INDEX([idx_noncls_include_exceptorderid]))
WHERE orderid<11072
GO
위 에서 알 수 있 듯 이 색인 을 덮어 쓰 는 비용 은 기본 메 인 키 로 색인 을 모 으 는 성능 보다 조금 더 좋 으 며,동시에 우 리 는 다음 과 같은 두 가지 IO 대 가 를 볼 수 있다.
상기 덮어 쓰기 인덱스 와 기본 집합 인덱스 의 대 비 를 통 해 우 리 는 IO 를 효과적으로 줄 일 수 있다 는 점도 매우 명확 하 다.물론 아래 의 INCLUDE 인덱스 대비 도 또 다른 좋 은 방안 이다.
INCLUDE 비 집합 인덱스 만 들 기
USE TSQL2012
GO
CREATE NONCLUSTERED INDEX [ix_noncls_include] ON [TSQL2012].[Sales].[Orders] (
shipcity
) INCLUDE (shipaddress, shipregion, orderid)
이로써 우 리 는 북 마크 룩 업,RID 룩 업,키 룩 업 을 제외 하고 색인 과 덮어 쓰기 색인 을 사용 합 니 다.
기왕 위 와 같은 두 가지 방식 이 있 으 니,우 리 는 마 땅 히 취사선택 을 해 야 한다.양자 중 누구의 성능 이 더 좋 을 까?우 리 는 이어서 상술 한 두 사람의 지출 차 이 를 비교 할 것 이다.
북 마크 룩 업 등 두 가지 방식 의 차 이 를 비교 제거 합 니 다.
USE TSQL2012
GO
SELECT orderid, shipaddress, shipcity, shipregion
FROM Sales.Orders WITH(INDEX(idx_all_cover))
WHERE shipcity = ' '
GO
SELECT orderid, shipaddress, shipcity, shipregion
FROM Sales.Orders WITH(INDEX(ix_noncls_include))
WHERE shipcity = ' '
GO
우 리 는 위 에서 알 고 있 는 바 와 같이 양자 지출 은 별 차이 가 없다.물론 우리 가 두 번 째 방식 을 해결 방안 으로 삼 는 경향 이 있다 고 믿는다.여기까지 거의 끝 난 셈 이지 만,또 하나의 작은 문제 가 있 습 니 다.우 리 는 이전에 orderid 의 집합 색인 을 만 들 었 습 니 다.그 다음 에 솔 루 션 에 도 orderid 의 비 집합 색인 을 추 가 했 습 니 다.굳이 추가 해 야 합 니까?제거 해 보 겠 습 니 다.
CREATE NONCLUSTERED INDEX idx_noncls_cover_exceptorderid
ON Sales.Orders(shipcity,shipaddress,shipregion)
CREATE NONCLUSTERED INDEX idx_noncls_include_exceptorderid
ON Sales.Orders(shipcity) INCLUDE(shipaddress,shipregion)
orderid 비교 양자 지출 차이 제거:
USE TSQL2012
GO
SELECT orderid, shipaddress, shipregion
FROM Sales.Orders WITH(INDEX([idx_noncls_cover_exceptorderid]))
WHERE shipaddress = ' '
GO
SELECT orderid, shipaddress, shipregion
FROM Sales.Orders WITH(INDEX([idx_noncls_include_exceptorderid]))
WHERE shipaddress = ' '
GO
위 에서 알 수 있 듯 이 비 집합 색인 열 은 집합 색인 을 만 든 열 을 포함 할 필요 가 없다.그렇다면 사실은 어떤 것 일 까?
결론:사실 모든 비 집합 색인 열 에는 집합 색인 을 만 든 열 이 포함 되 어 있 지 않 습 니 다.집합 색인 을 만 드 는 열 은 비 집합 색인 집합 열의 일부분 이기 때 문 입 니 다.즉,표 의 열 에 집합 색인 을 만 들 면 비 집합 색인 집합 열 에는 이 집합 색인 이 포함 되 어 있 습 니 다.
총결산
이 절 에서 우 리 는 문제 의 해결 에 대해 비교적 상세 하 게 던 져 서 조회 성능 을 향상 시 켰 다.자,여기 서 끝내 고 다음 절 에 다시 만 나 자.간단 한 내용,깊이 있 는 이해
이상 은 본 고의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 면 댓 글 을 남 겨 서 교류 할 수 있 고 저 희 를 많이 응원 해 주 셨 으 면 좋 겠 습 니 다!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
깊이 중첩된 객체를 정확히 일치 검색 - PostgreSQL목차 * 🚀 * 🎯 * 🏁 * 🙏 JSON 객체 예시 따라서 우리의 현재 목표는 "고용주"사용자가 입력한 검색어(이 경우에는 '요리')를 얻고 이 용어와 정확히 일치하는 모든 사용자 프로필을 찾는 것입니다. 즐거운 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.