긴 열이 성능 및 디스크 사용량에 어떤 영향을 줍니까?


26

현재 프로젝트에서 너무 자주 발생하여 열을 몇 문자로 확장해야합니다. 에서 varchar(20)varchar(30)와에 이렇게.

실제로 얼마나 중요합니까? 이것이 얼마나 최적화되어 있습니까? 일반 "입력"필드에 100 자 또는 200 자 또는 500 자만 허용하면 어떤 영향이 있습니까? 이메일에는 320 자만 사용할 수 있으므로 좋습니다. 제한이 있습니다. 그러나 200보다 큰 전자 메일 주소를 기대하지 않기 때문에 200으로 설정하면 무엇을 얻을 수 있습니까?

일반적으로 테이블에는 100.000 개가 넘는 행과 최대 20 개 또는 30 개의 열이 없습니다.

우리는 지금 SQL Server 2008을 사용하지만 다른 DB가이 문제를 어떻게 처리하는지 아는 것은 흥미로울 것입니다.

예상대로 영향이 매우 낮은 경우 DBA를 설득하기 위해 좋은 주장 (링크로 백업?)을 얻는 것이 도움이 될 것입니다.이 장거리 편집증은 실제로 필요하지 않습니다.

그것이 있다면, 나는 여기에 배울 것입니다 :-)

답변:


12

귀하의 질문에 대한 구체적인 대답은 (적어도 Oracle 및 다른 데이터베이스의 경우) 필드의 길이는 중요하지 않으며 데이터의 길이 만 중요하다는 것입니다. 그러나 이것은 필드를 최대 허용 길이로 설정할지 여부와 관련된 결정 요인으로 사용해서는 안됩니다. 필드 크기를 최대화하기 전에 고려해야 할 몇 가지 다른 문제가 있습니다.

포맷팅 필드의 크기에 따라 데이터를 포맷하는 클라이언트 도구는 특별한 포맷팅 고려 사항이 필요합니다. 예를 들어 Oracle의 SQL * Plus는 기본적으로 데이터가 한 문자 길이 인 경우에도 Varchar2 열의 최대 크기를 표시합니다. 비교…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

불량 데이터 필드 길이는 불량 데이터 를 포착 / 방지하기위한 추가 메커니즘을 제공합니다. 인터페이스는 100 자 필드에 3000자를 삽입하지 않아야하지만 해당 필드가 4000 자로 정의 된 경우에는 그럴 수 있습니다. 데이터 입력 단계에서 오류가 발생하지 않지만 다른 응용 프로그램이 데이터를 처리하고 질식하려고하면 시스템이 더 이상 다운되지 않을 수 있습니다. 예를 들어, 나중에 Oracle에서 필드를 인덱싱하기로 결정하면 블록 크기와 연결에 따라 최대 키 길이를 초과하게됩니다. 만나다…

create index i1 on f1(a);

메모리 클라이언트 응용 프로그램이 최대 크기를 사용하여 메모리를 할당하면 응용 프로그램은 필요한 것보다 훨씬 더 많은 메모리를 할당합니다. 이를 피하기 위해 특별한 고려가 필요합니다.

문서 필드의 크기는 데이터에 대한 다른 데이터 문서 포인트를 제공합니다. 모든 테이블 t1, t2, t3 등과 모든 필드 f1, f2, f3 등을 호출 할 수 있지만 의미있는 이름을 지정하면 데이터를 더 잘 이해할 수 있습니다. 예를 들어, 미국에 고객이있는 회사의 주소 테이블에 State라는 필드가 두 문자 인 경우 두 문자 상태 약어가 입력됩니다. 반면에 필드가 100 자이면 전체 상태 이름이 필드에 나타날 것으로 예상 할 수 있습니다.


말씀 드린대로, 변화에 대비하는 것이 현명한 것 같습니다. 오늘날 모든 제품 이름이 20 자에 해당한다고해서 항상 그렇게되는 것은 아닙니다. 배 밖으로 나가서 1000으로 만들지 말고 그럴듯한 확장을위한 공간을 남겨 두십시오.



문서는 다른 곳에서는 보지 못했지만 여기에 추가 한 좋은 것입니다.
jeteon

9

여기 당신에게 좋은 출발점이 있습니다.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

나는 당신의 원래 질문을 오해했을 것입니다. 참조 할 다른 링크를 찾을 수 있는지 확인해 보겠습니다.

데이터 유형 선택에 대한 참조는 다음과 같습니다. http://sqlfool.com/2009/05/performance-considerations-of-data-types/

varchar (20)에서 varchar (30)으로 변경하면 작은 것처럼 보일 수 있지만 잠재적 문제를 인식하려면 데이터베이스 구조의 작동 방식에 대해 더 많이 이해해야합니다. 예를 들어 varchar (30)로 이동하면 열의 팁 포인트 (30 바이트를 모두 사용해야 함)를지나 한 페이지 (8060 바이트 미만)에 저장할 수 있습니다. 이로 인해 사용 된 디스크 공간이 증가하고 성능이 저하되며 트랜잭션 로그에 추가 오버 헤드가 발생합니다.

데이터베이스 구조에 대한 링크는 다음과 같습니다. http://technet.microsoft.com/en-us/sqlserver/gg313756.aspx

다음은 페이지 분할 및 trx 로깅을위한 것입니다. http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH


7

다음 SO 질문에서 찾은 또 다른 흥미로운 점을 공유한다고 생각했습니다.

https://stackoverflow.com/questions/148398/are-there-any-disadvantages-to-always-using-nvarcharmax

원래 답변 : Nick Kavadias

max 또는 text 필드를 사용하지 않는 이유는 SQL Server Enterprise Edition에서도 [온라인 인덱스 다시 작성] [1], 즉 REBUILD WITH ONLINE = ON을 수행 할 수 없기 때문입니다.

[1] : http://msdn.microsoft.com/en-us/library/ms188388%28SQL.90%29.aspx "온라인 인덱스 재 구축"

n / varchar (max) 열을 임의로 추가 할 때 이것이 큰 단점이라고 생각하며 MS 사이트에 따르면 온라인 인덱스 다시 작성에 대한 이러한 제한은 SQL Server 2008, 2008 R2 및 Denali에 남아 있습니다. 따라서 SQL Server 2005에만 국한되지 않습니다.

고마워, Jeff


6

경우에 따라 varchar 필드에 할당하는 공간의 양은 메모리 내 정렬에 할당 된 메모리의 양에 영향을줍니다.

SQLWorkshops.com에서 프레젠테이션이 자극적이라고 생각한 것을 발견했습니다.이 프레젠테이션은 char / varchar 필드에 충분한 메모리가 할당되지 않아 주문 정렬이 tempdb로 넘겨지는 경우에 대해 설명합니다.

http://webcasts2.sqlworkshops.com/webcasts.asp

이 웹 캐스트는 다음 웹 사이트에서도 기사로 제공되었습니다.

http://www.mssqltips.com/tip.asp?tip=1955

이 프리젠 테이션에서 정렬중인 컬럼은 char / varchar 컬럼이 아니지만 메모리에서 varchar 컬럼에 할당 된 공간의 양에 따라 쿼리 성능이 달라질 수 있습니다.


4

ANSI_PADDING을 설정 하시겠습니까?

결국 많은 공백이 생깁니다 ...


3

디스크 공간 및 문자 길이와 만 관련이 있습니다. 물론 char 데이터 유형 및 이러한 유형의 데이터에 대한 인덱스 검색은 정수보다 느리게 작동하지만 이것은 또 다른 토론입니다.

Varchar 데이터 형식은 "가변"데이터 형식이므로 varchar (500)의 제한을이 필드의 최대 문자 길이보다 설정하면이 필드의 최대 문자 길이입니다. 최소 길이는 0과 500 사이 일 수 있습니다. 반면에 청구 된 디스크 공간은 10, 30 또는 500 문자 필드마다 다릅니다.

때로는 데이터 유형 varchar (800) 및 null 값에 대해 17 바이트를 사용했으며 삽입 된 각 문자에 대해 하나 이상의 바이트를 추가했습니다. 예를 들어 400 자 문자열에는 디스크에서 417 바이트가 사용되었습니다.


3

실제 최대 길이가 <= 20 인 경우 varchar (20) 또는 varchar ((8000)의 열로 만든 테이블간에 차이가 있다고 생각하지 않습니다.

반면에, 어떤 경우에는 사용자에게 더 긴 줄을 저장할 수있는 기회를주는 것이 더 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.