MySQL VARCHAR과 TEXT 데이터 형식의 차이점은 무엇입니까?

버전 5.0.3 이후 (VARCHAR은 65,535 바이트가되고 후행 공백 잘림이 중단됨)이 두 데이터 유형간에 큰 차이가 있습니까?

나는 차이점 목록을 읽고 있었고 두 가지 참고 사항은 다음과 같습니다.

BLOB 및 TEXT 열의 인덱스의 경우 인덱스 접두사 길이를 지정해야합니다. CHAR 및 VARCHAR의 경우 접두사 길이는 선택 사항입니다. 7.5.1 절“열 색인”을 참조하십시오.

과

BLOB 및 TEXT 열은 DEFAULT 값을 가질 수 없습니다.

따라서 TEXT 데이터 유형에 대한이 두 가지 제한 때문에 왜 varchar (65535)보다 사용합니까? 다른 것보다 성능에 영향이 있습니까?

mysql database-design datatypes

— 데릭 다우니
소스

데이터에 65535 자 이상을 원할 때

— BlackICE

다음은 VARCHAR와 텍스트 사이의 벤치 마크에 대한 꽤 좋은 포럼 스레드의 http://forums.mysql.com/read.php?24,105964,105964

— 구분

목록에 실제로 명시적인 세부 사항을 배치하는 데 도움이되고 이미 나열된 차이점 목록이 있으므로 이것이 DBA에 필요한 질문인지 확실하지 않습니다. 이 목록에서 인용 한 목록과 제공 한 이유 가 충분 하지 않은 이유 가 있습니까? 그렇지 않으면 나는 VtC에 갈 것이다

— jcolebrand

내 질문을 업데이트했지만 확실하지 않은 한 가지 분명한 이유는 서로의 성능입니다. 분명하지 않은 다른 이유가 있는지 확실하지 않은 경우

— Derek Downey

그래서 당신이 요구하는 것이 다른 것의 성능 특성이라는 것이 공평합니까?

— jcolebrand

분할 된 기본적인 문제를 설명 약간의 정보에 링크 (가 성능 차이입니다)하지만, 하나는 항상 더 나은 다른 것보다 있다는 말을 간단 충분하지 않습니다. (그렇지 않으면 둘 다 가질 이유가 없습니다.) 또한 MyISM에서 VARCHAR의 최대 64k 크기는 필드 당이 아니라 레코드 당입니다.

기본적으로 데이터베이스 레코드에 문자열을 저장하는 4 가지 방법이 있습니다.

고정 길이
C 스타일 문자열 (문자열 끝에 NULL 또는 유사한 문자로 표시)
파스칼 스타일 문자열 (길이를 나타내는 몇 바이트, 문자열)
포인터 (문자열을 다른 곳에 저장)

MyISM은 VARCHAR에 # 3과 비슷한 것을 사용하고 TEXT에 대한 하이브리드 접근법을 사용하여 레코드의 문자열 시작을 레코드에 저장 한 다음 나머지 문자열을 저장합니다. InnoDB는 VARCHAR과 유사하지만 완전한 TEXT 필드를 레코드 외부에 저장합니다.

1 & 4를 사용하면 레코드의 내용이 항상 같은 길이이므로 문자열이 필요하지 않지만 이후에 필요한 것이 있으면 건너 뛰기가 더 쉽습니다. # 2와 # 3은 짧은 문자열에 대해서는 나쁘지 않습니다 ... # 2는 마커를 계속 찾아야하지만 # 3은 건너 뛸 수 있습니다 ... 문자열이 길어질수록이 특정 용도로는 # 2가 악화됩니다. 케이스.

실제로 문자열을 읽어야하는 경우 레코드를 읽어야하므로 # 4가 느려집니다. 그런 다음 데이터베이스가 처리하는 방식에 따라 디스크의 다른 곳에 저장 될 수있는 문자열을 읽으십시오. # 1은 항상 매우 간단하며, 다시 # 2의 경우 문자열이 길어질수록 비슷한 문제가 발생하지만 # 3은 매우 작은 문자열의 경우 # 2보다 약간 나쁘지만 길어질수록 좋습니다.

그런 다음 저장 요구 사항이 있습니다 ... # 1은 항상 고정 길이이므로 대부분의 문자열이 최대 길이가 아닌 경우 팽창이 발생할 수 있습니다. # 2에는 1 바이트의 여분의 바이트가 있습니다. # 3은 일반적으로 최대 길이가 255 인 경우 2 바이트를 더, 64k 최대 인 경우 4 바이트를 추가합니다. # 4에는 포인터 길이와 # 3의 규칙이 있습니다.

MySQL 5.1 내 특정 구현의 경우 MyISM 상태에 대한 문서는 다음과 같습니다.

진정한 VARCHAR 유형 지원; VARCHAR 컬럼은 1 또는 2 바이트에 저장된 길이로 시작합니다.
VARCHAR 컬럼이있는 테이블은 고정 또는 동적 행 길이를 가질 수 있습니다.
테이블에서 VARCHAR 및 CHAR 열 길이의 합계는 최대 64KB 일 수 있습니다.

InnoDB 동안 :

레코드 헤더의 가변 길이 부분에는 NULL 열을 나타내는 비트 벡터가 포함됩니다. 인덱스에서 NULL 일 수있는 열의 수가 N이면 비트 벡터는 CEILING (N / 8) 바이트를 차지합니다. 예를 들어, NULL 일 수있는 9-15 개의 열이있는 경우 비트 벡터는 2 바이트를 사용합니다. NULL 인 열은이 벡터의 비트 이외의 공간을 차지하지 않습니다. 헤더의 가변 길이 부분에는 가변 길이 열의 길이도 포함됩니다. 각 길이는 열의 최대 길이에 따라 1 바이트 또는 2 바이트를 사용합니다. 인덱스의 모든 열이 NOT NULL이고 고정 길이를 갖는 경우 레코드 헤더에는 가변 길이 부분이 없습니다.
NULL이 아닌 가변 길이 필드 각각에 대해 레코드 헤더에는 열 길이가 1-2 바이트로 포함됩니다. 열의 일부가 오버 플로우 페이지에 외부 적으로 저장되거나 최대 길이가 255 바이트를 초과하고 실제 길이가 127 바이트를 초과하는 경우에만 2 바이트가 필요합니다. 외부 저장 열의 경우 2 바이트 길이는 내부 저장 부품의 길이에 외부 저장 부품에 대한 20 바이트 포인터를 더한 값을 나타냅니다. 내부 부분은 768 바이트이므로 길이는 768 + 20입니다. 20 바이트 포인터는 열의 실제 길이를 저장합니다.

...

데이터베이스를 다룰 때 다른 많은 것들과 마찬가지로, 요구 사항에 가장 적합한 것이 확실하지 않은 경우 비슷한 데이터 및 사용량으로 벤치마킹하고 데이터베이스의 작동 방식을 확인하십시오.

— 조
소스

스레드는 MySQL이 BLOB 및 텍스트 필드를 inline forums.mysql.com/read.php?24,105964,267596#msg-267596

— Michael Mior

Nitpick ... 모든 실제적인 목적을 위해 어느 엔진에서든 64KB 제한이 없습니다. LONGTEXT그리고 LONGBLOB적절한 예이다. C 스타일 문자열은 MySQL에서 사용하지 않습니다 (내가 아는). InnoDB는 '하이브리드'접근법을 사용하지만 행 크기, row_format 등에 따라 더 복잡합니다. "고정 된"길이로 문자열을 저장하는 것은 실제로 일정한 길이 (country_code, zip_code 등)를 제외하고는 권장되지 않습니다. . InnoDB는 4를 가진다 ROW_FORMATs; 본문은 그중 하나 또는 둘에 대해서만 설명합니다.

— Rick James

SELECT가 임시 테이블을 작성해야하는 경우 (예 : 결과 정렬) MEMORY 테이블 또는 MyISAM 테이블을 작성합니다. 메모리가 더 효율적입니다. MEMORY에는 TEXT 및 BLOB를 금지하는 제한이 있습니다. 따라서 SELECT 는 VARCHAR보다 TEXT로 느리게 실행될 수 있습니다.

— 릭 제임스
소스