데이터베이스 설계/성능 전문가를위한 자료입니다.SQL Server int vs nvarchar 성능 비교?
테이블을 디자인 할 때 열에 int 또는 nvarchar (128)를 사용하도록 선택했습니다. 공간이 문제가 아닌 것으로 가정합니다. 내 질문은 성능을
내가 INT 열이 검색
where ID = 12324
또는 내가 NVARCHAR 열이 검색 할 때 (키가 전체 가치, 그래서 내가 연산자 LIKE 사용하지 않는) 줄 것이다있다
where Key = 'my str'
나는 그것이 중요하지 않습니다 작은 데이터 세트에 대한 확신 만의이 데이터 행의 수백만에있을 것입니다 가정하자.
INT가 빠를 것이다 - 여기 왜 : 당신이 그것을에 INT 키와 인덱스 페이지가있는 경우
그래서 페이지 당 약 200 항목의 NVARCHAR을 (의 128) ca se는 10 배의 인덱스 페이지를 사용합니다.
이러한 인덱스 페이지를로드하고 검색하면 훨씬 많은 I/O 작업이 발생합니다.
물건을 짧게 만들려면 가능한 경우 INT를 사용하십시오.
성능의 주요 문제는 필드 크기입니다. int은 4 바이트이고, nvarchar(128)은 254 바이트입니다.
이 모든 것이 SQL 서버에 의해 관리되어야하므로 int을 관리하는 것이 nvarchar(128)보다 훨씬 빠릅니다.
공간은 항상 데이터베이스의 문제입니다. 키가 넓을수록 페이지 당 항목 수가 적어지고 집계 및 합계 값으로 스캔되는 페이지가 많아 IO가 많아지고 성능이 떨어집니다. 클러스터 된 인덱스의 경우 리프에 룩업 키 (클러스터 된 키)를 재생해야하므로 클러스터되지 않은 각 인덱스에이 문제가 곱해집니다. 따라서 nvarchar(128) 키는 일 것입니다. 거의은 INT보다 항상 나쁜 것입니다.
반면에 INT 키를 사용하지 마십시오. 검색어을 고려하여 항상 적절한 키 을 사용하십시오. 항상 nvarchar (128) 열 값으로 쿼리 할 경우 좋은 클러스터 된 키 후보가됩니다. 으로 nvarchar (128) 키를 사용하면 가능성이 높음 좋은 클러스터 된 키 후보가됩니다.
+1 : Natural> 인공 키이지만 자연 키 IME는 거의 없습니다. –
(특히 조인이있는 경우) 성능을 위해 int를 사용하고 데이터 무결성을위한 잠재적 인 자연어 키에 고유 인덱스를 넣습니다.
+1 좋은 지적. 또한 CPU가 문자열이 아닌 int를 처리하도록하는 작업이 조금 적습니다. 수백만 행을 사용하면 무시할 수없는 차이가 발생할 수 있습니다. 이것에 대한 실제 성능 테스트를보고 싶습니다. –