SQL varchar 열 길이에 대한 모범 사례

SQL varchar 열 길이에 대한 모범 사례

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

2년 전에 문을 닫았어요

이 질문을 개선하다

매번 새로운 SQL 테이블을 설정하거나 새로운 SQL 테이블을 추가합니다.varchar컬럼을 기존 테이블로 이동합니다.한 가지 궁금한 점이 있습니다.length.

예를 들어 다음과 같은 컬럼이 있다고 가정해당 컬럼은name타입의varchar그래서 길이를 정해야 돼요.20자 이상의 이름은 생각나지 않지만 알 수 없습니다.하지만 20을 사용하는 대신 항상 다음 2^n 숫자로 반올림합니다.이 경우 32를 길이로 하겠습니다.컴퓨터 과학자의 관점에서 보면 숫자 2^n이 더 좋아 보이거든요even다른 수치보다 더 잘 다룰 수 있을 것 같아요.

한편, 예를 들어 MSQL 서버는 varchar 컬럼을 작성하도록 선택한 경우 기본 길이 값을 50으로 설정합니다.그게 생각나네요.왜 50일까요? 그냥 난수인가요, 아니면 평균 열 길이에 근거한 건가요?

또한 SQL 서버 구현(MySQL, MS SQL, Postgres 등)마다 최적의 열 길이 값이 다를 수도 있습니다.

내가 알고 있는 DBMS는 어떤 '최적화'도 하지 않는다.VARCHAR와 함께2^n길이가 a를 사용하는 것보다max2의 거듭제곱이 아닌 길이.

이전 SQL Server 버전에서는 실제로 처리되었습니다.VARCHAR길이가 255인 경우 최대 길이가 큰 경우와는 다릅니다.아직도 그런지는 모르겠어요.

거의 모든 DBMS에서 필요한 실제 스토리지는 문자 수에 의해서만 결정됩니다.max사용자가 정의하는 길이.따라서 스토리지(및 대부분의 경우 성능)의 관점에서 열을 다음과 같이 선언해도 아무런 차이가 없습니다.VARCHAR(100)또는VARCHAR(500).

를 참조해 주세요.max에 제공되는 길이VARCHAR칼럼은 기술적/물리적 것이 아니라 일종의 제약(또는 비즈니스 규칙)으로 사용됩니다.

포스트그레용SQL을 사용하는 것이 가장 좋습니다.text길이 제한 없이CHECK CONSTRAINT비즈니스에서 필요로 하는 글자 수를 제한합니다.

이 요건이 변경되면 체크 제약 조건을 변경하는 것이 테이블을 변경하는 것보다 훨씬 빠릅니다(테이블을 다시 쓸 필요가 없기 때문입니다).

Oracle 등에도 동일하게 적용할 수 있습니다.Oracle에서는 다음과 같습니다.VARCHAR(4000)대신text그래도.

물리적인 스토리지의 차이가 있는지 어떤지는 모르겠습니다.VARCHAR(max)및 예: VARCHAR(500)SQL Server에서 사용할 수 있습니다.단, 사용 시 퍼포먼스에 영향이 있는 것 같습니다.varchar(max)에 비해varchar(8000).

이 링크 참조(Erwin Brandstetter가 코멘트로 게시)

2013-09-22 편집

bigown의 코멘트에 대해서:

Postgres 9.2 이전 버전(초기 응답 작성 시 사용할 수 없음)에서는 컬럼 정의를 변경하면 테이블 전체가 다시 작성되었습니다(여기 참조).9.2는 더 이상 해당되지 않으며, 120만 행이 있는 테이블의 열 크기를 늘리는 데 0.5초밖에 걸리지 않는다는 것이 간단한 테스트에서 확인되었습니다.

Oracle의 경우에도 큰 테이블의 변경에 시간이 걸리는 것으로 보아 이는 사실인 것 같습니다.varchar기둥.그러나 나는 그것에 대한 어떠한 참고 자료도 찾을 수 없었다.

MySQL의 경우 설명서에는 "대부분 원본 테이블의 임시 복사본을 만듭니다."라고 나와 있습니다.그리고 제 테스트 결과,ALTER TABLE120만 행(Postgres를 사용한 테스트와 동일)이 있는 테이블에서 컬럼 크기를 늘리는 데 1.5분이 걸렸습니다.그러나 MySQL에서는 "회피책"을 사용하여 체크 제약 조건을 사용하여 열의 문자 수를 제한할 수 없습니다.

SQL Server의 경우 이 문제에 대한 명확한 설명을 찾을 수 없었지만 실행 시간을 사용하여 크기를 늘릴 수 있습니다.varcharcolumn(위의 120만 행 테이블)은 개서가 이루어지지 않았음을 나타냅니다.

2017-01-24 편집

SQL Server에 대해 (적어도 부분적으로는) 잘못 알고 있었던 것 같습니다.Aaron Bertrand의 이 답변을 참조해 주십시오.이 답변은 Aaron Bertrand의 선언된 길이가nvarchar또는varchar컬럼은 퍼포먼스에 큰 차이를 가져옵니다.

VARCHAR(255)그리고.VARCHAR(2)디스크에서 정확히 동일한 공간을 차지합니다!따라서 크기를 제한해야 하는 유일한 이유는 크기를 줄이려는 특정 요구가 있는 경우입니다.그렇지 않으면 모두 255로 합니다.

특히 정렬을 할 때는 컬럼이 클수록 공간을 많이 차지하기 때문에 퍼포먼스가 저하될 경우 이를 고려하여 컬럼을 작게 만들어야 합니다.단, 이 테이블에서 1행만 선택해도 255행으로 할 수 있기 때문에 문제가 되지 않습니다.

참고 항목: MySQL에 가장 적합한 varchar 크기는 무엇입니까?

새로운 SQL 테이블을 설정할 때마다 2^n이 더 "짝수"가 되는 것에 대해 같은 생각을 합니다. 하지만 여기서의 답을 요약하면, 단순히 varchar(2^n) 또는 varchar(MAX)를 정의하는 것만으로 스토리지 공간에 큰 영향은 없습니다.

단, 높은 varchar() 제한을 설정할 경우 스토리지 및 성능에 대한 잠재적인 영향을 예상해야 합니다.예를 들어 varchar(MAX) 열을 생성하여 전체 텍스트 색인이 포함된 제품 설명을 보관한다고 가정합니다.설명의 99%가 500자밖에 되지 않는 경우, 갑자기 누군가가 해당 설명을 위키피디아 기사로 대체하면 예상치 못한 스토리지 및 성능 저하가 발생할 수 있습니다.

Bill Karwin에서 고려해야 할 또 다른 사항:

성능에 영향을 줄 수 있는 한 가지 방법이 있습니다. MySQL에서는 임시 테이블과 MEMORY 테이블이 VARCHAR 열을 최대 길이까지 패딩하여 고정 길이 열로 저장합니다.필요한 최대 크기보다 훨씬 큰 VARCHAR 열을 설계하면 필요한 것보다 더 많은 메모리가 사용됩니다.이는 캐시 효율성, 정렬 속도 등에 영향을 미칩니다.

기본적으로 약간 더 큰 규모에서 합리적인 비즈니스 제약과 오류를 생각해 보십시오.@oneday가 지적한 바와 같이 영국의 성은 보통 1~35자 사이입니다.바르샤르(64)로 만들기로 결정한다면, 당신은 정말로 아무것도 해치지 않을 것이다.최대 666자로 알려진 이 남자의 성을 저장하지 않는 한 말이죠이 경우 varchar(1028)가 더 적절할 수 있습니다.

그리고 도움이 되는 경우, varchar 2^5 ~ 2^10을 채우면 다음과 같이 됩니다.

varchar(32)     Lorem ipsum dolor sit amet amet.

varchar(64)     Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie

varchar(128)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas

varchar(256)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt

varchar(512)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt
                dolor tellus, sit amet porta neque varius vitae. Seduse molestie
                lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
                mollis diam pretium gravida. In facilisis vitae tortor id vulput
                ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie

varchar(1024)   Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt
                dolor tellus, sit amet porta neque varius vitae. Seduse molestie
                lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
                mollis diam pretium gravida. In facilisis vitae tortor id vulput
                ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie
                dapibus leo lobortis eleifend. Vivamus vitae diam turpis. Vivamu
                nec tristique magna, vel tincidunt diam. Maecenas elementum semi
                quam. In ut est porttitor, sagittis nulla id, fermentum turpist.
                Curabitur pretium nibh a imperdiet cursus. Sed at vulputate este
                proin fermentum pretium justo, ac malesuada eros et Pellentesque
                vulputate hendrerit molestie. Aenean imperdiet a enim at finibus
                fusce ut ullamcorper risus, a cursus massa. Nunc non dapibus vel
                Lorem ipsum dolor sit amet, consectetur Praesent ut ultrices sit

가장 좋은 값은 기본 도메인에 정의된 데이터에 적합한 값입니다.

도메인에 따라서는VARCHAR(10)최적의 환경Name아트리뷰트, 다른 도메인용VARCHAR(255)가장 좋은 선택일 수도 있어요

a_horse_with_no_name의 답변에 다음과 같은 내용을 추가할 수 있습니다.

열을 VARCHAR(100) 또는 VACHAR(500)로 선언해도 아무런 차이가 없습니다.

-- try to create a table with max varchar length
drop table if exists foo;
create table foo(name varchar(65535) not null)engine=innodb;

MySQL Database Error: Row size too large.

-- try to create a table with max varchar length - 2 bytes for the length
drop table if exists foo;
create table foo(name varchar(65533) not null)engine=innodb;

Executed Successfully

-- try to create a table with max varchar length with nullable field
drop table if exists foo;
create table foo(name varchar(65533))engine=innodb;

MySQL Database Error: Row size too large.

-- try to create a table with max varchar length with nullable field
drop table if exists foo;
create table foo(name varchar(65532))engine=innodb;

Executed Successfully

다음과 같이 길이 바이트와 nullable 바이트를 잊지 마십시오.

name varchar(100) not null1 바이트(길이) + 최대 100 문자(latin1)가 됩니다.

name varchar(500) not null2 바이트(길이)+최대 500 문자(latin1)가 됩니다.

name varchar(65533) not null2 바이트(길이) + 최대 65533 문자(latin1)가 됩니다.

name varchar(65532)2 바이트(길이) + 최대 65532 문자(latin1) + 1 늘바이트가 됩니다.

이것이 도움이 되기를 바랍니다:)

항상 비즈니스 도메인 전문가에게 확인하십시오.고객이라면 업계 표준을 찾아보십시오.예를 들어 해당 도메인이 자연인의 성(surname)인 경우, 저는 영국 기업의 경우 개인 정보에 대한 UK Govertalk 데이터 표준 카탈로그에서 성(姓)이 1에서 35자 사이임을 발견합니다.

최근에는 확인하지 않았지만 Oracle에서는 JDBC 드라이버가 쿼리 실행 중에 반환되는 결과 세트를 유지하기 위해 메모리 청크를 예약한다는 것을 알고 있습니다.메모리 청크의 크기는 열 정의와 가져오기 크기에 따라 달라집니다.따라서 varchar2 열의 길이는 예약된 메모리 양에 영향을 미칩니다.이 때문에 수년 전에는 항상 varchar2(4000)(당시 최대)를 사용했고 가비지 수집 효율이 현재보다 훨씬 떨어졌기 때문에 심각한 성능 문제가 발생했습니다.

어떤 의미에서는 당신이 옳습니다. 단, 2^8자 미만의 문자는 여전히 데이터 바이트로 등록됩니다.

VARCHAR < 255로 되어 있는 기본 문자를 같은 공간을 소비하는 것으로 간주하는 경우.

255는 과도한 입력을 줄이고 싶은 경우를 제외하고 적절한 기준선 정의입니다.

언급URL : https://stackoverflow.com/questions/8295131/best-practices-for-sql-varchar-column-length