varchar 2는 varchar 255보다 효율적입니까?

Question

약 5 자만 사용하려고해도 장고를 사용하고 CharField (max_length = 255)를 설정하고 있습니다. 이것은 덜 효율적입니까? 나는 그것이 varchar로는별로 중요하지 않다고 읽었지만 하드 드라이브 공간을 절약하여 필요할 때만 지정할 수 있다고 읽었습니다.

Answer 1

일반적으로 varchar (255)는 varchar (1)만큼의 저장소가 필요합니다. 각각의 경우에 테이블은 문자열 테이블과 길이에 대한 포인터와 같은 것을 저장합니다. 예 : 4 바이트 오프셋 + 1 바이트 크기 = 행당 고정 된 5 바이트, 오버 헤드 용.

실제 내용은 물론 문자열 테이블에있는 문자열만큼 긴 문자열 테이블에 있습니다. 따라서 5 문자 이름을 varchar (255) 필드에 저장하면 5 개의 오버 헤드 바이트 + 5 개의 content 바이트 = 10 바이트 만 사용됩니다.

varchar (10) 필드를 사용하면 정확히 같은 양을 사용하지만 10 바이트보다 긴 문자열 만 자릅니다.

---

물론 구체적인 수치는 스토리지 엔진 구현에 따라 다릅니다.

Answer 2

하드 드라이브 공간은 저렴하지만 CPU 캐시 공간이 비쌉니다. 더 큰 필드보다 더 작은 필드를 맞출 수 있습니다.

Answer 3

큰 공간을 불필요하게 사용하는 대신 모든 문자를 읽을 필요가 없으므로 더 많은 저장 공간을 제공 할뿐만 아니라 빠른 실행 속도를 제공하는 공간을 활용하십시오. varchar (255)를 할당하고 'abc'텍스트를 추가하면 문자 'a', 'b', 'c'및 기타를 공백으로 읽습니다.

따라서 항상 최대 공간을 유지하는 대신 필요한 공간 인 u를 사용하십시오.

Answer 4

포함 된 VARCHAR는 overhead for storing the string length을 제외하고, 당신이 그것을에 저장 한 문자열보다 더 많은 공간을 차지하지 않습니다

+------------------------------------------+---------------------------------+ 
| Value  | CHAR(4) Storage Required | VARCHAR(4) Storage Required | 
+------------+-----------------------------+---------------------------------+ 
| ''   | ' '  4 bytes   | ''   1 byte    | 
| 'ab'  | 'ab '  4 bytes   | 'ab'   3 bytes   | 
| 'abcd'  | 'abcd'  4 bytes   | 'abcd'  5 bytes   | 
| 'abcdefgh' | 'abcd'  4 bytes   | 'abcd'  5 bytes   | 
+------------+-----------------------------+---------------------------------+ 

을하지만, 당신이 정말로에만 다음, 5 개 문자를 필요로 문자 사용을 고려 경우 (5) 테이블에 다른 가변 너비 열 (예 : varchars, text 또는 blob)이없는 경우. 자주 을 변경 MyISAM 테이블의 경우

, 당신이 모든 가변 길이 열 (VARCHAR, BLOB 및 TEXT)를 피하려고한다 : 그럼 당신은 어떤 performance advantages 휴대 않는 길이 레코드를 해결 한 것입니다. 테이블에 동적 행 형식을 사용하는 경우 단일 가변 길이 열까지 포함됩니다.13 장, 저장소 엔진을 참조하십시오.

Answer 5

varchar 대신 char을 사용할 경우주의해야 할 점은 문자 집합이 할당해야하는 공간에 영향을 미친다는 것입니다. 예를 들어 해당 열의 문자 집합이 utf8 인 경우 단일 문자를 저장하는 데 3 바이트가 필요할 수 있습니다.

저장되는 내용에 관계없이 char 열의 크기가 고정되어 있으므로 데이터베이스는 최악의 경우를 수용해야합니다. 따라서 MySQL은 실제로 모든 행에 5 바이트의 싱글 바이트 문자 만 저장하더라도 해당 char (5) 열에 항상 15 바이트를 할당해야합니다.

varchar는 저장된 각 행에 필요한 것만 사용하므로 동일한 5 개의 단일 바이트 문자는 6 또는 7 바이트 만 차지합니다.여분의 1 바이트 또는 2 바이트는 실제 길이를 추적하기위한 것입니다. 싱글 바이트 문자 집합에서 최대 255 자의 varchar의 경우 MySQL은 실제 너비를 저장하기 위해 1 바이트 만 할당해야합니다. 너비가 256에서 65,535 인 varchar는 길이를 저장하기 위해 2 바이트가 필요하며 1 바이트 문자 집합으로 가정합니다.

utf8 varchar (255)는 255 * 3 바이트의 저장 공간이 필요할 수 있으므로 MySQL은 길이를 저장하기 위해 2 바이트를 할당해야합니다. 이 정보의 대부분은 MySQL 문서 here에서 다룹니다.

너비를 65,535로 선언 할 수 있지만 최대 유효 크기 (바이트)는 65,532입니다. 그러나 저장하는 문자 집합과 문자에 따라 최대 다중 바이트 문자를 저장할 수 있습니다.

Paul이 지적했듯이 전체 행을 너비로 고정 할 수있게하려면 char을 사용하고 싶을 수도 있습니다. 특히 고정 오프셋 (offset) 때문에 특정 탐색이 더 빨라질 수있다 (예를 들어, 최초의 1000 행을 스킵).

또한 열에 대한 업데이트와 관련하여 고려해야 할 성능 문제가 있습니다. char (5)가 있고 1 문자로 시작한 다음 5 문자로 값을 업데이트하면 행을 제자리에서 업데이트 할 수 있습니다. varchar를 사용하면 저장소 엔진 구현에 따라 전체 행을 새 위치에 다시 작성해야 할 수 있습니다.

마지막으로, MySQL이 영구 테이블에서 결과 세트를 정렬하기 위해 메모리 내장 임시 테이블을 생성해야하는 경우 고정 길이 레코드를 사용합니다. 그래서, 당신이 생각했던 것보다 더 큰 varchar 컬럼을 위해 메모리에 더 많은 공간을 할당합니다. 이 내용은 메모리 저장소 엔진 테이블 용 MySQL 문서에서 다룹니다. 나는 또한 MySQL이 디스크 기반의 종류에 대해서도 이것을 수행한다고 믿는다.