MySQL에서 TEXT 필드 대신 VARCHAR 필드를 사용하는 이유

배경

데이터베이스에 길이가 불확실한 직렬화된 데이터 세그먼트를 저장할 때 많은 사람들이 테이블 스키마에서 필드를 VARCHAR(2000)으로 설계합니다.

그러나 길이가 불확실한 경우 TEXT 유형을 대신 사용하지 않는 이유는 무엇일까요? 어떤 사람들은 TEXT가 쿼리 성능에 영향을 미친다고 말합니다.

정말 그럴까요? 이 기사에서는 다음을 살펴봅니다.

텍스트란 무엇인가

TEXT는 MySQL의 가변 길이 데이터 유형으로, TINYTEXT, TEXT, MEDIUMTEXT 및 LONGTEXT를 포함합니다. 일반적으로 많은 양의 텍스트 데이터를 저장하는 데 사용되며 스토리지 제한은 다음과 같습니다.

TINYTEXT: 0 - 255바이트
TEXT: 0 - 65,535바이트
MEDIUMTEXT: 0 - 16,777,215바이트
LONGTEXT: 0 - 4,294,967,295바이트

TEXT 저장 방법

각 BLOB 또는 TEXT 값은 내부적으로 별도로 할당된 객체로 표시되지만 다른 데이터 유형은 테이블이 열릴 때 열당 한 번 할당되는 스토리지 공간을 갖습니다.

문자열 유형 데이터를 저장할 때 InnoDB는 768바이트 이상의 고정 길이 필드를 가변 길이 필드로 인코딩하고 오버플로 페이지에 저장합니다. 768바이트보다 작은 데이터는 데이터 행에 직접 저장됩니다. 따라서 다른 문자열 유형을 사용할 때는 768바이트 이상인 데이터를 저장하지 마십시오.

TEXT의 제한 사항

TEXT는 기본값을 가질 수 없습니다.
TEXT 필드를 인덱싱할 때는 접두사 길이를 지정해야 합니다.
인덱스 항목을 비교할 때 후행 공백이 채워집니다. 고유 인덱스가 필요한 경우 중복 키 오류가 발생할 수 있습니다.
TEXT 필드는 특히 길 수 있습니다. 정렬할 때 처음 max_sort_length 바이트(기본값은 1024)만 사용됩니다. 이 값은 변수를 수정하여 조정할 수 있습니다.

-- max_sort_length 보기
SELECT @@max_sort_length;

-- max_sort_length 설정
SET max_sort_length = 2048;

임시 테이블로 처리할 때 서버는 MEMORY 스토리지 엔진이 TEXT 유형을 지원하지 않기 때문에 메모리 내부가 아닌 디스크의 테이블을 사용합니다.
TEXT 객체의 크기는 유형에 따라 결정되지만 실제로 전송 가능한 최대 크기는 사용 가능한 콘텐츠 및 통신 버퍼 크기에 따라 제한됩니다. 이는 max_allowed_packet 변수를 변경하여 조정할 수 있습니다.

-- max_allowed_packet 보기
SELECT @@max_allowed_packet;

-- max_allowed_packet 설정
SET max_allowed_packet = 67108864;

결론

TEXT는 많은 양의 텍스트 데이터를 저장하는 데 사용할 수 있습니다. 그러나 여러 가지 이유로 TEXT를 사용하는 것은 권장되지 않습니다.

성능 문제

TEXT는 내부적으로 별도로 할당된 객체로 표시되므로 스토리지 및 검색 중에 추가 작업 및 리소스 소비가 필요합니다.
TEXT 필드가 특히 큰 경우 읽기 작업으로 인해 메모리 압박이 증가하여 전체 시스템 성능에 영향을 미칠 수 있습니다.
MEMORY 스토리지 엔진은 TEXT를 지원하지 않으므로 임시 테이블을 사용할 때 TEXT 필드의 데이터는 메모리에서 직접 읽는 대신 디스크에서 읽습니다.

인덱싱 제한 사항

인덱스는 쿼리 성능을 향상시킬 수 있지만 TEXT 필드를 인덱싱하는 데에는 특정 제한 사항과 복잡성이 있습니다.

고유 인덱스로 사용하면 중복 키 오류가 발생할 수 있습니다.
전체 텍스트 인덱스를 생성하려면 추가 계산 및 공간이 필요합니다. TEXT 필드가 너무 크면 성능에 부정적인 영향을 미칠 수 있습니다.

따라서 테이블 스키마 설계에서 TEXT 유형을 사용하지 않는 것이 좋습니다. 반드시 사용해야 하는 경우 다음 방법을 고려하십시오.

TEXT 필드를 독립적인 테이블로 분리하고 기본 키를 통해 기본 테이블에 연결합니다.
필요하지 않은 경우 TEXT 필드를 읽지 마십시오. 예를 들어 SELECT *를 사용하지 마십시오.
큰 필드의 경우 OSS(객체 스토리지 서비스)에 저장하는 것을 고려하십시오.

저희는 백엔드 프로젝트 호스팅을 위한 최고의 선택, Leapcell입니다.

Leapcell은 웹 호스팅, 비동기 작업 및 Redis를 위한 차세대 서버리스 플랫폼입니다.

다국어 지원

Node.js, Python, Go 또는 Rust로 개발하십시오.

무제한 프로젝트를 무료로 배포

사용량에 대해서만 비용을 지불하십시오. 요청이나 요금이 없습니다.

탁월한 비용 효율성

유휴 요금 없이 사용한 만큼 지불하십시오.
예: $25로 평균 응답 시간 60ms에서 694만 개의 요청을 지원합니다.

간소화된 개발자 경험

간편한 설정을 위한 직관적인 UI.
완전 자동화된 CI/CD 파이프라인 및 GitOps 통합.
실행 가능한 통찰력을 위한 실시간 메트릭 및 로깅.

간편한 확장성 및 고성능

고도의 동시성을 쉽게 처리할 수 있도록 자동 확장.
운영 오버헤드가 없으므로 구축에만 집중하십시오.

설명서에서 자세히 알아보십시오!

X에서 저희를 팔로우하세요: @LeapcellHQ