SQLServer 성능 최적화-함수 인덱스 또는 Hash 인덱스 간접 구현

SQLServer 에는 함수 색인 이 없습니다.어떤 장면 에서 조회 할 때 필드 의 일부분 에 따라 조회 하거나 특정한 계산 을 거 친 후에 조회 해 야 합 니 다.함수 나 다른 방식 으로 필드 에 작용 하면 색인 사용 이 제한 되 지만 함수 색인 과 유사 한 기능 을 간접 적 으로 실현 할 수 있 습 니 다.
또 하 나 는 검색 필드 가 크 거나 필드 가 많 을 때 만들어 진 색인 이 약간 무 겁 고 효율 도 높 지 않 으 면 작은'대체 성'필드 를 사용 하여 등가 로 교체 하 는 것 을 고려 해 야 한 다 는 것 이다.Hash 색인 과 유사 하 다.
본 고 는 상술 한 두 가지 문제 의 해결 방식 을 간략하게 소개 하 였 으 니 참고 하 시기 바 랍 니 다.
1.계산 열 에 색인 을 만들어'함수 색인'기능 실현
SQLServer 는 표를 만 들 때 계산 열 을 사용 할 수 있 습 니 다.이 계산 열 을 통 해 함수 색인 기능 을 실현 할 수 있 습 니 다.예 를 들 어 설명 하 겠 습 니 다.

Create Table TestFunctionIndex
(
  id int identity(1,1),
  val varchar(50),
  subval as LOWER(SUBSTRING(val,10,4)) persisted --          
)
GO

--            
create index idx_subvar on TestFunctionIndex(subval)
GO

--  10W     
insert into TestFunctionIndex(val) values (NEWID())
go 100000

색인 이 있 는 필드 에서 함 수 를 사용 하면 색인 을 사용 할 수 없습니다.

계산 열 에서 직접 조회 하면 색인 을 정상적으로 사용 할 수 있다.

이상 은 계산 열 에 색인 을 만 들 면 계산 열 에 있 는 색인 에 따라 찾 을 수 있 으 며 필드 에 함수 나 다른 조작 을 직접 사용 하지 않 아 필드 에 색인 이 있어 도 사용 할 수 없 는 상황 을 피 할 수 있 습 니 다.
보충:
테스트 에서 계산 열 필드 에 색인 을 만 들 면 원시 필드 에서 함수 가 계산 열 함수 와 같 을 때 계산 열 에 있 는 색인 을 신기 하 게 사용 할 수 있다 는 것 을 신기 하 게 발견 했다.이 를 통 해 알 수 있 듯 이 SQLServer 는 저희 가 주의 하지 않 은 곳 에서 도 많은 공 을 들 였 습 니 다.

2.비교적 긴 필드 나 여러 필드 의 Hash 값 을 생 성하 여 원본 필드 대신 조회 하거나 연결 하여 조회 효율 을 높 인 다.
개발 과정 에서 흔히 볼 수 있 는 또 다른 상황 은 자주 사용 되 는 조회 조건 필드 가 비교적 길 거나 표 가 연 결 될 때 연결 조건 필드 가 비교적 많다 는 것 이다.
필드 나 조회 조건 에 색인 이 있 더 라 도 필드 가 길 거나 조건 이 많 기 때문에 조회 효율 에 영향 을 줄 수 있 습 니 다.
이러한 상황 은 원래 의 비교적 긴 필드 를 작은 필드 로 만 드 는 것 을 적당 하 게 고려 하거나 여러 필드 에서 비교적 짧 은 데이터 형식 을 생 성하 여 조회 의 효율 을 높 여야 한다.
예 를 들 어 만약 에 이런 표 가 있다 면 Name 필드 는 제 가 모 의 한 것 입 니 다.Name 은 비교적 긴 필드 이 고 검색 도 해 야 합 니 다.
검색 필드 가 길 고 색인 대가 가 너무 크다 는 뜻 이다.이 럴 때 는 작은 등가 필드 로 대체 하 는 것 을 고려 해 야 한다.
다음은 어떤 방식 으로 비교적 긴 필드 의 Hash 값 을 계산 하여 등가 교 체 를 한다

테스트 데이터 생 성 시 뮬 레이 션

Create table testHashColumn
(
  id int identity(1,1),
  QueryName nvarchar(100),
  HashName AS CAST( HASHBYTES('MD2',QueryName) AS UNIQUEIDENTIFIER) persisted
)
GO

create index idx_HashName ON testHashColumn(HashName)
GO

--               
DECLARE @i int = 0
while @i<10000
begin 
  INSERT INTO testHashColumn (QueryName) VALUES (CONCAT('               ',@i))
  set @i = @i+1
end

우 리 는 Name 이라는 이름 이 nvarchar(100)이라는 것 을 알 고 있 습 니 다.이 필드 는 색인 을 하면 안 되 는 것 이 아니 라 상황 이 복잡 하면 실제 적 으로 이 필드 보다 더 클 수 있 습 니 다.색인 을 만 드 는 것 이 너무 넓 어서 색인 공간 이 너무 크 고 효율 적 인 데 어느 정도 영향 을 줄 수 있 습 니 다.
Name 필드 에'대체'필드 를 만 드 는 것 을 고려 할 수 있 습 니 다.(상기 HashName AS CAST(HASHBYTES('MD2',QueryName)AS UNIQUEIDENTIFIER)persisted 이 계산 열)
이 필드 의 첫 번 째 선택 은 실제 값 과 일일이 대응 해 야 합 니 다.또한'대체'를 요구 하 는 필드 유형 에 대한 요구 가 상대 적 으로 적 습 니 다.물론 방법 도 여러 가지 가 있 습 니 다.예 를 들 어 checksum 함 수 를 이용 하여 하나의 검사 값 을 생 성 하 는 것 입 니 다.그러나 실제 관찰 에 따 르 면 checksum 이 생 성 한 검사 값 은 중복 될 수 있 습 니 다.즉,두 개의 서로 다른 문자열 로 같은 검사 값 을 생 성 합 니 다.
예 를 들 어 이 문 제 를 쉽게 검증 할 수 있 습 니 다.서로 다른 문자열 에 대해 계산 한 후에 같은 검증 과

따라서'대체'필드 를 만 들 때 계산 값 의 유일 성 을 고려 해 야 한다.
HASHBYTES 암호 화 함 수 를 사용 하여 문자열 을 암호 화한 다음 암호 화 된 데이터 에 UNIQUEIDENTIFIER 를 생 성하 면 중 복 될 확률 이 훨씬 적 습 니 다.
CAST(HASHBYTES('MD2','베 이 징 신시 점 과학기술 문화 미디어 유한 공사 999')AS UNIQUEIDENTIFIER 방식 을 통 해 이 긴 필드 에 UNIQUEIDENTIFIER 형식의 필드 를 생 성 할 수 있 습 니 다.
물론 이 방법 만 있 는 것 이 아니 라 복잡 하 게 할 수 있 습 니 다.유일한 긴 필드 가 생 성 된 짧 은 필드 도 유일 하 게 목적 을 달성 할 수 있 습 니 다.
아래 의 조 회 를 참고 하면 HashName 에서 계산 한 값 과 계산 열 을 비교 할 수 있 으 며,검색 필드 색인 의 크기 를 어느 정도 줄 이 고 목적 을 달성 할 수 있 는 효 과 를 얻 을 수 있 습 니 다.

캡 처 하면 HashName 필드 의 색인 을 사용 할 수 있 으 며,원본 Query Name 이라는 긴 필드 에 색인 을 만 드 는 것 도 피 할 수 있 으 며,공간 을 절약 하고 조회 효율 을 높 일 수 있 습 니 다.
3.논리 키 가 여러 필드 일 때 여러 필드 에'대체'성의 유일한 필드 를 생 성 합 니 다.
어떤 상황 에서 업무 수요 나 디자인 도 좋다(예 를 들 어 세 번 째 범례,BC 범례,네 번 째 범례,심지어 다섯 번 째 범례 에 이 르 지 못 했다).표 연결 할 때 여러 필드 가 있다.
예 를 들 어 이런 모습:

SELECT *
FROM TableNameA a
INNER JOIN TableNameB b
  ON a.key=b.key
    AND a.Type = b.Type
    AND a.Status = b.Staus
    AND a.CreationTime = b.CreationTime
    AND a.***=b.***
where ***

표 와 관련 이 있 을 때 연결 조건 이 매우 많 습 니 다.만약 그렇다면 가장 좋 은 상황 은 비교적 넓 은 복합 색인 을 만 드 는 것 입 니 다.그러나 이렇게 되면 색인 의 너비 와 부피 가 커지 고 사용 할 때 효율 도 어느 정도 영향 을 줍 니 다.이 경우 TableNamea 와 TableNameB 에서 여러 연결 필드(Key+Type+Status+CreationTime+**)를 이용 하여 예제 2 와 유사 한 계산 열 을 만 들 고 계산 열 에 색인 을 만 든 다음 표 로 연결 할 때 다음 과 같은 방식 으로 대체 할 수 있 습 니 다.

SELECT *
FROM TableNameA a
INNER JOIN TableNameB b
  ON a.HashValue=b.HashValue
WHERE ***

항상 이것 은 공간 으로 시간 을 바 꾸 는 사고(식별 자 와 유사 한 필드 를 불필요 하 게 저장 하고 조회 효율 을 향상 시 키 는 것)이다.'대체'필드 를 생 성 하 는 사상 은 두 가지 가 있다.첫째,충분 하 게 작 아야 한다.둘째,원시 값 으로 대체 필드 를 생 성 하 는 유일 성 이다.
요약:SQLServer 에는 함수 색인 과 Hash 색인 이 없 으 며,일부 업무 수요 나 성능 을 고려 하기 위해 서 는 유사 한 기능 이 필요 합 니 다.공간 교환 시간 과 유사 한 방법 으로 이 루어 집 니 다.함수 색인 이나 Hash 색인 과 유사 한 기능 을 변통 적 으로 실현 할 수 있 습 니 다.다른 데이터베이스 에서 함수 인덱스 와 Hash 인덱스 의 효과 에 도 달 했 습 니 다.(원리 가 다 를 수 있 지만)주의해 야 할 것 은 계산 열 을 만 들 거나 Hash 값 을 대체 할 때 계산 방식 에 주의 하여 생 성 된 Key 값 의 유일 성 을 확보 하 는 것 이다.물론 실현 방식 은 수요 에 따라 스스로 선택 할 수 있 고 모든 길 은 로마 로 통한다.
이상 은 본 고의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.또한 저 희 를 많이 지지 해 주시 기 바 랍 니 다!