490M 행과 55GB의 테이블 스페이스가있는 테이블이 있으므로 행당 약 167 바이트입니다. 이 테이블에는 a VARCHAR(100), a DATETIME2(0)및 a의 세 가지 열 이 SMALLINT있습니다. 텍스트의 평균 길이 VARCHAR22 +를위한 2 원 데이터는 행 당 약 32 바이트이어야하므로 필드 21.5 관한 VARCHAR대 6 DATETIME216 비트 정수, 2.
위의 공간은 인덱스가 아니라 데이터 일뿐입니다. 속성 | 아래에보고 된 값을 사용하고 있습니다. 저장 | 일반 | 데이터 공간.
물론 약간의 오버 헤드 가 있어야 하지만 행 당 135 바이트는 특히 큰 테이블의 경우 많이 보입니다. 왜 이것이 될 수 있습니까? 다른 사람이 비슷한 승수를 보았습니까? 필요한 추가 공간의 양에 영향을 줄 수있는 요인은 무엇입니까?
비교를 위해 두 INT필드와 1M 행 으로 테이블을 만들려고했습니다 . 필요한 데이터 공간은 8 바이트의 원시 데이터와 비교하여 행당 17 바이트 인 16.4MB입니다. 실제 테이블과 동일한 텍스트로 채워진 INT및 다른 테스트 테이블 VARCHAR(100)은 행 당 39 바이트 (44 K 행)를 사용하며 28 + 조금 더 기대합니다.
따라서 생산 테이블에는 상당히 많은 오버 헤드가 있습니다. 더 크니까요? 인덱스 크기가 대략 N * log (N) 일 것으로 예상하지만 실제 데이터에 필요한 공간이 비선형 인 이유는 알 수 없습니다.
모든 포인터에 미리 감사드립니다!
편집하다:
나열된 모든 필드는 NOT NULL입니다. 실제 테이블에는 VARCHAR필드와 DATETIME2필드에 순서대로 클러스터 된 PK가 있습니다. 두 테스트에서 첫 번째 INT는 (클러스터 된) PK입니다.
중요한 경우 : 테이블은 핑 결과 레코드입니다. 필드는 URL, 핑 날짜 / 시간 및 대기 시간 (밀리 초)입니다. 데이터가 지속적으로 추가되고 업데이트되지는 않지만 데이터는 주기적으로 삭제되어 URL 당 시간당 몇 개의 레코드로 줄어 듭니다.
편집하다:
여기 에서 매우 흥미로운 답변 은 많은 읽기와 쓰기가있는 인덱스의 경우 재구성이 유리하지 않을 수 있음을 나타냅니다. 필자의 경우 소비되는 공간이 문제이지만 쓰기 성능이 더 중요하면 연약한 인덱스를 사용하는 것이 좋습니다.