우리 회사는 다양한 테이블과 많은 필드가있는 레거시 데이터베이스를 보유하고 있습니다.데이터베이스 (최대) 필드 길이가 성능에 영향을 줍니까?
많은 필드에는 절대로 도달 할 수없는 큰 제한 (예 : NVARCHAR(MAX))이있는 것 같습니다.
일반적으로 입력되는 것보다 최대 너비 또는 2 ~ 3 배 큰 값으로 임의로 필드를 성능에 부정적인 영향을 미치나요?
성능을 필드 길이와 어떻게 조화시켜야합니까? 잔액이 있습니까?
가이 질문에 두 부분입니다 :
VARCHAR 상처 성능을 통해 NVARCHAR를 사용합니까? 예, 유니 코드 필드에 데이터를 저장하면 스토리지 요구 사항이 두 배로 증가합니다. 이 필드에 저장된 데이터는 SQL Server 2008 R2가 출시 될 때까지 필요로하는 크기의 2 배이며 unicode compression을 포함합니다. 테이블 스캔은 버퍼 캐시에서 메모리에 저장할 수있는 데이터의 양이 2 배 길고 절반 만 소요됩니다
VARCHAR (MAX), NVARCHAR (MAX) 및 이러한 종류의 필드를 사용하는 경우 직접적인 문제는 아니지만 테이블을 인덱싱해야하는 경우에는 다음 작업을 수행 할 수 없습니다. SQL Server 2005/2008/R2에서 온라인으로 해당 인덱스를 다시 작성하십시오. (Denali는 MAX 필드가있는 테이블을 개선하여 일부 인덱스를 온라인으로 재구성 할 수 있습니다.)
'VARCHAR (MAX)'및 관련 필드를 인덱싱 할 수 없습니다. – Justin
죄송합니다. 좀 더 구체적으로 설명해야합니다. 이러한 표에 색인을 생성해야하는 경우 해당 색인을 온라인으로 재구성 할 수 없습니다. 이러한 필드가있는 테이블은 SQL Server 2005/2008/2008R2에서 온라인으로 다시 인덱싱 할 수 없습니다. –
예, 쿼리 최적화 프로그램은 페이지에 맞는 행 수를 추측 할 수 있습니다. varchar 필드가 필요한 것보다 많이 있으면 SQL Server는 내부적으로 잘못된 행 수를 추측 할 수 있습니다.
쿼리 최적화 프로그램은 '행이 얼마나 넓은가'를 사용하여 '얼마나 많은 행이 각 행에 적합 할 수 있는지'를 추정합니다. 페이지'. –
성능면에서 대부분의 경우 대답은 아니오입니다. 응용 프로그램 수준에서 성능을 분석 할 수 있다고 생각합니다. 데이터를 수집하고 요구 사항을 얻은 다음 몇 가지 분석을 수행하십시오. 병목 현상은 응용 프로그램 코드, SQL 또는 스키마 설계로 인해 발생할 수 있습니다.
하지만 VARCHAR MAX)'- 큰 단점이있을 수 있습니다. (모든 색인은 최대 900 바이트를 가질 수 있습니다 - 최대 (MAX) 열 *은 최대 2GB가 될 수 있습니다. 어느 인덱스에도 포함될 수 없음) –
관련/중복 http://stackoverflow.com/questions/4378795/sql-performance-is-there-any-performance-hit-using-nvarcharmax-instead-of-nvar –
가능 [varchar (max) everywhere?] (http://stackoverflow.com/questions/2091284/varcharmax-everywhere) – Justin