SQL Server 데이터베이스 에서 위 열 및 위 열 의 의미 에 대한 상세 한 설명

SQL Server 의 위 열
오후 에 QQ 그룹 에서 색인 을 모 으 는 저장 소 에 대해 토론 하 는 사람 이 있 습 니 다.색인 표를 모 으 는 것 에 대해 서 는 색인 키+색인 키 를 모 으 는 것 이 아 닙 니 다.비 집합 색인 표 에 대해 색인 은 색인 키+RowId 를 저장 합 니 다.이것 은 상식 이 어야 하 며 이에 대해 구체 적 으로 설명 하지 않 습 니 다.
여기 서 주로 언급 된 RowId 는 약간의 사 고 를 불 러 일 으 켰 다.
그럼 이 RowId 는 무엇 입 니까?좀 더 직관 적 으로 RowId 의 정 보 를 볼 수 있 을까요?무슨 뜻 을 대표 합 니까?이것 도 물론 입 니 다.
Oracle 에 있 는 표 에는 위 열 개념 이 있 는데 바로 표를 조회 할 때select rowid，* from Table를 더 하면 위 열 을 조회 하 는 것 이다.
SQL Server 에 도 이러한 위조 열 이 있 습 니 다.SQL Server 에서 이 위조 열 은 데이터 줄 의 물리 적 주소 라 고 볼 수 있 습 니 다.다음은 이 RowId 와 RowId 의 의 미 를 간단하게 살 펴 보 겠 습 니 다.
위 열의 테스트
간단 한 시 계 를 만 들 고,다음은 이 시 계 를 빌려 위 열 을 살 펴 보 겠 습 니 다.

CREATE TABLE Test
(
 id int identity(1,1),
 name varchar(50)
)
GO

INSERT INTO Test VALUES (NEWID())
GO 100

SQL Server 에 공개 되 지 않 은 위 열'%%pysloc%%'가 있 습 니 다.즉,조회 할 때 모든 표 에 이 필드 를 추가 할 수 있 습 니 다.예 를 들 어 아래 와 같이 표 의 모든 줄 의 위 열 을 찾 을 수 있 습 니 다.

이 위 열 의 유형 은binary(8),즉 8 개의 바이트 가 있 습 니 다.위의 그림DATALENGTH(%%physloc%%) as Len,%pysloc%%가 되 돌아 온 기록 의 물리 적 주 소 를 참고 하 십시오.그 중에서 앞의 네 개의 바이트 는 페이지 번 호 를 표시 하고 중간 두 개의 바이트 는 파일 번 호 를 표시 하 며 마지막 두 개의 바이트 는 슬롯 번 호 를 표시 합 니 다.
위 열의 의 미 를 더욱 편리 하 게 관찰 하기 위해 sqlserver 는 공개 되 지 않 은 시스템 함수 sys.fn 를 제공 합 니 다.PhysLocFormatter,다음은sys.fn_PhysLocFormatter이 함 수 를 빌려 이 위조 열 을 계속 관찰 합 니 다
아래 그림 에서 위 열 에 있 는 정 보 를 뚜렷하게 볼 수 있다.

예 를 들 어 첫 줄 에 있 는(1:73:0)은 위 에서 말 했 듯 이 그 중에서 앞의 네 개의 바이트 가 페이지 번 호 를 표시 하고 중간 에 두 개의 바이트 가 파일 번 호 를 표시 하 며 마지막 두 개의 바이트 가 슬롯 번 호 를 표시 한다.(1:73:0)이런 형식 은sys.fn_PhysLocFormatter포맷 을 거 친 후의 결과 이다.
파일 번호 1 을 맨 앞 에 놓 고 가운데 73 은 페이지 번호(page number)이 고 마지막 0 은 슬롯 번호(sloc number)입 니 다.
이 필드 의 의 미 를 대충 말씀 드 리 겠 습 니 다.SQL Server 에 대한 저장 소 는 기본 적 인 인식 일 뿐 그렇지 않 으 면 구름 속 에 보 입 니 다.
1.먼저 파일 번호 가 무엇 인지 말 합 니 다.
캡 처 할 때 파일 번 호 는 데이터베이스 의 데이터 파일 번호 입 니 다.여 기 는 데이터 파일 이 하나 밖 에 없습니다.파일 번 호 는 1 입 니 다.표를 만 들 때 기본 값(여기 도 만 들 수 있 습 니 다)은 fileid=1 의 파일 위 에 세 워 집 니 다.fileid=2 는 로그 파일 입 니 다.더 이상 말 하지 않 겠 습 니 다.

2.그 다음은 페이지 번호 입 니 다.페이지 번 호 는 현재 이 표 의 데이터 페이지(8kb 의 최소 할당 단위)에 분 배 된 페이지 번호 입 니 다.Test 이 표 의 페이지 상황 을 살 펴 보 겠 습 니 다.
DBCC IND 명령 에 힘 입 어 이 표 에 배 정 된 페이지 정 보 를 조회 하 는데,이 중 77 번 페이지 는 IMA 도 면 으로 어떤 일 인지 IMA 페이지 에 대해 서 는 설명 이 많 지 않다.
73 번 페이지 야 말로 데 이 터 를 진정 으로 저장 하 는 페이지 로 위의 1:73:0 중의 73 과 마찬가지 로 문제 가 없다.
　　
3.마지막 으로 홈 번 호 를 살 펴 보 자.홈 번호 의 개념 은 SQL Server 의 데이터 페이지 에 대해 기본 적 인 인식 을 가 져 야 한다.여기 서 네티즌 의 그림 을 도용 해 야 한다.
슬롯 번호 란 데이터 페이지 에 각 페이지 에 여러 줄 의 데 이 터 를 저장 하 는 것 입 니 다.슬롯 번 호 는 각 줄 의 데이터 의 오프셋 을 표시 하 는 데 사 용 됩 니 다.큰 말로'각 줄 의 데 이 터 를 저장 하 는 주소 공간 이 시작 되 는 위치'입 니 다.각 줄 의 데이터 의 총 길 이 는 다 르 기 때 문 입 니 다.(가 변 길이 열 이 존재 하 는 경우)각 줄 이 차지 하 는 저장 공간 도 다 릅 니 다.홈 번호 나 줄 오프셋 은 각 줄 의 데이터 가 페이지 내 에서 시작 하 는 위 치 를 설명 하 는 것 이다.
그러나sys.fn_PhysLocFormatter포맷 된 슬롯 번 호 는 다음 과 같은 캡 처 의 오프셋 이 아니 라 N 번 째 데이터 줄 의 이 N 의 정보 이기 때문에 첫 번 째 줄 의 슬롯 번 호 는 1 이 고 두 번 째 줄 의 슬롯 번 호 는 2 이다.이런 식 으로 유추 하면 첫 번 째 페이지 가 가득 차 면 두 번 째 페이지 부터 저장 하고 슬롯 번 호 는 0 부터 번 호 를 매 기 며 누적 된다.
　　
　　
이로써 SQL Server 의 위 열 에 대해 흔히 말 하 는 RowId 에 대해 간단 한 인식 을 가지 게 되 었 다.
SQL Server 데이터베이스 에서 위 열 RowId 는 데이터 줄 의 물리 적 주소 라 고 볼 수 있 습 니 다.다른 데이터베이스 에 있 는 위 열(RowId)이 물리 적 주소 인지 아 닌 지 는 확실 하지 않 습 니 다(그 럴 가능성 이 높 습 니 다).
여기 서 처음에 말 한 문 제 를 간단하게 말씀 드 리 겠 습 니 다.
왜 SQL Server 의 집합 표(집합 색인 이 있 는 표)는 데 이 터 를 저장 할 때'색인 키+집합 색인 키'를 저장 합 니까?비 집합 색인 표 에 대해 서 는 색인 키+RowId 를 저장 합 니까?
또는 반대로 색인 표 의 비 집합 색인 저장 소 는'색인 키+집합 색인 키'가 아니 라'색인 저장 소 는 색인 키+RowId'입 니 다.
하나의 상식 으로서 집합 색인 은 집합 색인 순서에 따라 저장 해 야 한다.이것 은 집합 색인 표 의 줄 데이터 물리 적 위치 에 변화 가 생 길 수 있다 는 것 을 의미한다.예 를 들 어 모두 가 알 고 있 는'페이지 분할(page split)'에서 변화 가 생 겼 고 데이터 줄 의 물리 적 위치 에 변화 가 생 겼 을 때 집합 색인 이 아 닌 것 이 색인 키+RowId 라면그러면 이 RowId 도 변화 가 필요 합 니 다.이 변 화 는 당연히 일정한 성능 을 소모 해 야 합 니 다.이러한 상황 을 방지 하기 위해 서 는 집합 표 의 비 집합 색인 을 상대 적 으로 변 하지 않 는 색인 키+집합 색인 키 로 저장 합 니 다.데이터 줄 의 물리 적 위치 가 변 할 때 집합 색인 키 가 상대 적 으로 변 하지 않 기 때문에 이해 하기 어렵 지 않 습 니 다.
물론 집합 색인 표를 업데이트 할 때 집합 색인 키 값 을 직접 업데이트 하 는 예외 가 있 습 니 다.그러면 집합 색인 표 에서 현재 데이터 줄 의 물리 적 위치 에 변화 가 생 길 수 있 습 니 다.이 점도 재 미 있 으 므 로 서술 을 하지 않 습 니 다.
이 점 은 잰말놀이 와 마찬가지 로 SQL Server 의 집합 색인 과 비 집합 색인,그리고 저장 구조 에 대한 기본 적 인 인식 이 있어 야 이해 하기 쉽다.
최종 고에너지 경고
고에너지 경고,내 가 사람 을 오도 하 는 것 보다 함부로 비교 하 는 것 은 말 할 것 도 없고,위 에서 위 열 을 해석 하 는 함수sys.fn_PhysLocFormatter는 공개 되 지 않 은 함수 이 며,공개 되 지 않 은 함수 에 잠재 적 인 문제 가 있 을 수 있 습 니 다.사실은 이 함수 에 매우 심각 한 bug 가 있 습 니 다.
이 bug 는 물리 적 저장 위 치 를 분석 할 때 일정한 논리 적 오류 가 있 는 것 으로 이 문 제 는 세심 한 사람 이 분석 한 적 이 있다.
참고:https://www.jb51.net/article/124109.htm
현재 테스트 를 보면 SQL Server 2014 에 bug 가 존재 합 니 다.N 은 재작년 에 책 을 뜯 었 을 때 이런 함수 가 있다 는 것 을 알 았 습 니 다.그러나 이 함수 의 원인 을 언급 하고 싶 지 않 았 습 니 다.따라서 공개 되 지 않 은 함수 에 대해 검증 적 인 테스트 를 하지 마 십시오.다시 한 번 말씀 드 리 겠 습 니 다.이 함수 에 bug 가 있 으 니 신중하게 사용 하 십시오.
이 함수 의 소스 코드 를 첨부 하고 원문의 결론 을 참고 하 세 요.

create function sys.fn_PhysLocFormatter (@physical_locator binary (8))
 returns varchar (128)
as
 begin
 declare @page_id binary (4)
 declare @file_id binary (2)
 declare @slot_id binary (2)
 -- Page ID is the first four bytes, then 2 bytes of page ID, then 2 bytes of slot
 --
 select @page_id = convert (binary (4), reverse (substring (@physical_locator, 1, 4)))
 select @file_id = convert (binary (2), reverse (substring (@physical_locator, 5, 2)))
 select @slot_id = convert (binary (2), reverse (substring (@physical_locator, 7, 2)))
 return '(' + cast (cast (@file_id as int) as varchar) + ':'
 + cast (cast (@page_id as int) as varchar) + ':'
 + cast (cast (@slot_id as int) as varchar) + ')'
 end

문 제 는 reverse 함수 에 있다.
reverse 함수 의 역할 은 바이트 반전 이 아니 라 문자 반전 입 니 다.81-FE 사이 의 바이트 에 부 딪 혔 을 때 두 바이트 문자 로 여 겨 져 함께 조합 되 어 반전 작업 에 참여 하여 오류 가 발생 했 습 니 다.
총결산
본 고 는 SQL Server 의 위조 열 과 위조 열의 의 미 를 간단하게 논술 하고 위조 열 을 통 해 비 집합 색인 과 데이터 줄 의 저장 구조 에 대해 간단 한 이 해 를 가진다.
자,이상 이 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.