Loading...
MySQL 9.5 Reference Manual 9.5의 13.3.4 The BLOB and TEXT Types의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
BLOB은 가변 길이의 데이터를 담을 수 있는 바이너리 대형 객체입니다. 네 가지 BLOB 타입은 TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB입니다. 이들은 담을 수 있는 값의 최대 길이만 서로 다릅니다. 네 가지 TEXT 타입은 TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT입니다. 이들은 네 가지 BLOB 타입에 대응되며, 최대 길이와 저장소 요구 사항이 동일합니다.
Section 13.7, “Data Type Storage Requirements”를 참조하십시오.
BLOB 값은 바이너리 문자열(byte 문자열)로 취급됩니다. 이들은 binary 문자 집합과 콜레이션을 가지며, 비교와 정렬은 컬럼 값의 바이트에 대한 숫자 값에 기반합니다. TEXT 값은 비바이너리 문자열(문자열)로 취급됩니다. 이들은 binary가 아닌 문자 집합을 가지며, 해당 문자 집합의 콜레이션에 따라 정렬 및 비교됩니다.
스트릭트 SQL 모드가 활성화되어 있지 않은 상태에서 BLOB 또는 TEXT 컬럼에 컬럼의 최대 길이를 초과하는 값을 할당하면, 그 값은 맞도록 잘려(truncate) 경고가 발생합니다. 공백이 아닌 문자에 대한 잘림에 대해서는, 스트릭트 SQL 모드를 사용하여 경고 대신 에러가 발생하도록 하고, 값의 인서트를 막을 수 있습니다.
Section 7.1.11, “Server SQL Modes”를 참조하십시오.
TEXT 컬럼에 값을 인서트할 때, 값의 끝에 있는 과도한 후행 공백을 잘라낼 경우에는 SQL 모드와 관계없이 항상 경고가 생성됩니다.
TEXT 및 BLOB 컬럼에 대해서는, 인서트 시 패딩이 이루어지지 않으며 셀렉트 시에도 어떤 바이트도 제거되지 않습니다.
TEXT 컬럼에 인덱스가 있는 경우, 인덱스 엔트리 비교는 끝을 공백으로 패딩하여 수행됩니다. 이는 인덱스가 유니크 값을 요구한다면, 후행 공백의 개수만 다른 값에 대해서도 중복 키 에러가 발생한다는 의미입니다. 예를 들어, 테이블에 'a'가 포함되어 있을 때 'a '를 저장하려 하면 중복 키 에러가 발생합니다. 이는 BLOB 컬럼에는 해당되지 않습니다.
대부분의 측면에서, BLOB 컬럼은 원하는 만큼 클 수 있는 VARBINARY 컬럼으로 간주할 수 있습니다. 마찬가지로 TEXT 컬럼은 VARCHAR 컬럼으로 간주할 수 있습니다. BLOB 및 TEXT는 VARBINARY 및 VARCHAR와 다음과 같은 점에서 다릅니다:
BLOB 및 TEXT 컬럼에 대한 인덱스에서는 인덱스 프리픽스 길이를 명시해야 합니다. CHAR 및 VARCHAR의 경우 프리픽스 길이는 선택 사항입니다.
Section 10.3.5, “Column Indexes”를 참조하십시오.
BLOB 및 TEXT 컬럼은 DEFAULT 값을 가질 수 없습니다.
TEXT 데이터 타입에 BINARY 속성을 사용하면, 해당 컬럼에는 컬럼 문자 집합의 바이너리(_bin) 콜레이션이 할당됩니다.
LONG 및 LONG VARCHAR는 MEDIUMTEXT 데이터 타입으로 매핑됩니다. 이는 호환성 기능입니다.
MySQL Connector/ODBC는 BLOB 값을 LONGVARBINARY로, TEXT 값을 LONGVARCHAR로 정의합니다.
BLOB 및 TEXT 값은 매우 길 수 있으므로, 이를 사용할 때 다음과 같은 제약에 직면할 수 있습니다:
컬럼을 정렬할 때는 컬럼의 처음 max_sort_length 바이트만 사용됩니다. max_sort_length의 기본값은 1024입니다. 서버 시작이나 런타임 시 max_sort_length의 값을 증가시켜, 정렬이나 그룹핑에서 더 많은 바이트가 의미를 갖도록 할 수 있습니다. 어떤 클라이언트든 자신의 세션 max_sort_length 변수를 변경할 수 있습니다:
1mysql> SET max_sort_length = 2000; 2mysql> SELECT id, comment FROM t 3 -> ORDER BY comment;
임시 테이블을 사용하여 처리되는 쿼리 결과에 BLOB 또는 TEXT 컬럼이 존재하면, 해당 데이터 타입을 MEMORY 스토리지 엔진이 지원하지 않기 때문에 ( Section 10.4.4, “Internal Temporary Table Use in MySQL” 참조) 서버는 메모리 대신 디스크 상의 테이블을 사용하게 됩니다. 디스크 사용에는 성능 저하가 수반되므로, 쿼리 결과에 BLOB 또는 TEXT 컬럼이 정말 필요할 때만 포함시키십시오. 예를 들어, 모든 컬럼을 선택하는 SELECT * 사용은 피하십시오.
BLOB 또는 TEXT 객체의 최대 크기는 그 타입에 의해 결정되지만, 실제로 클라이언트와 서버 사이에서 전송할 수 있는 최대 값은 사용 가능한 메모리 양과 통신 버퍼의 크기에 의해 결정됩니다. max_allowed_packet 변수 값을 변경하여 메시지 버퍼 크기를 바꿀 수 있지만, 서버와 클라이언트 프로그램 양쪽에서 모두 변경해야 합니다. 예를 들어 mysql과 mysqldump 모두에서 클라이언트 측 max_allowed_packet 값을 변경할 수 있습니다.
Section 7.1.1, “Configuring the Server”, Section 6.5.1, “mysql — The MySQL Command-Line Client”, Section 6.5.4, “mysqldump — A Database Backup Program”를 참조하십시오.
또한 패킷 크기와 저장 중인 데이터 객체의 크기를 저장소 요구 사항과 비교해 보는 것도 좋습니다.
Section 13.7, “Data Type Storage Requirements”를 참조하십시오.
각 BLOB 또는 TEXT 값은 내부적으로 별도로 할당된 객체로 표현됩니다. 이는 테이블이 열릴 때 컬럼마다 한 번만 저장소가 할당되는 다른 모든 데이터 타입과는 대조됩니다.
일부 경우에는 미디어 파일과 같은 바이너리 데이터를 BLOB 또는 TEXT 컬럼에 저장하는 것이 바람직할 수 있습니다. 이와 같은 데이터를 다룰 때는 MySQL의 문자열 처리 함수가 유용할 수 있습니다.
Section 14.8, “String Functions and Operators”를 참조하십시오. 보안상의 이유 및 기타 이유로, 애플리케이션 사용자에게 FILE 권한을 부여하는 대신, 애플리케이션 코드를 사용하여 이 작업을 수행하는 것이 일반적으로 더 바람직합니다. 다양한 언어와 플랫폼에 대한 구체적인 사항은 MySQL Forums ( http://forums.mysql.com/)에서 논의할 수 있습니다.
참고
mysql 클라이언트 내에서 바이너리 문자열은 --binary-as-hex의 값에 따라 16진수 표기법을 사용하여 디스플레이됩니다. 해당 옵션에 대한 자세한 내용은
Section 6.5.1, “mysql — The MySQL Command-Line Client”를 참조하십시오.
13.3.3 The BINARY and VARBINARY Types
13.3.5 The VECTOR Type