'varchar(4000) 이상'에 해당되는 글 1건

1. mysql longtext 형 써도 되나?

테이블 반영 스키마 검수 중에 longtext 형으로 선언한 컬럼이 있어 확인해보니 약 4GB 까지나 되는 문자를 집어넣을 수 있게 되어있다.

컬럼 타입이 너무 큰데.. MEDIUMTEXT로 줄여야 하지 않나?..

이걸 써도 성능에 이슈가 없는지 확인해 보았다.

TEXT : 최대 65,535 개의 문자의 저장이 가능한 가변 길이 문자형.
필드 설정시 최대 크기를 지정하게 되어 있지 않음. 예를 들면 address text( 520 ) NOT NULL 가 아니라

address text NOT NULL로 해야오류 나지 않음
설계자가 520 byte의 문장을 입력하였다면 실제 저장 길이는 520+2 byte가 됨

MEDIUMTEXT, LONGTEXT도 최대 저장 가능 크기 외에는 성격이 같음

BLOB : BLOB는 데이타를 이진 데이타로 취급하는 것을 제외하고는 TEXT 자료형과 성격이 같다.

MEDIUMTEXT : 최대 16,777,215 개의 문자 저장 가능한 가변 길이 문자형,
MEDIUMBLOB : MEDIUMBLOB는 데이타를 이진 데이타로 취급하는 것을 제외하고는

MEDIUMTEXT 자료형과 성격이 같다.

LONGTEXT : 최대 4,294,967,295 개의 문자 저장 가능한 가변 길이 문자형,

- 가변길이다. 별이슈 없을 거 같긴한데.. 그래도 좀 더 확인해본다.
LONGBLOB : LONGBLOB는 데이타를 이진 데이타로 취급하는 것을 제외하고는 LONGTEXT 자료형과 성격이 같다.

MySQL: Is there a lack of performance by using LONGTEXT instead of MEDIUMTEXT?

The only difference is the length field in the row data. Using MEDIUMTEXT instead of LONGTEXT saves 1 byte per record.
If you have 100 million records, that saves 100 MB.
There was a time when that was a significant amount of disk space.
유일한 차이점은 행 데이터의 길이 필드다. LONGTEXT 대신 MEDITEXT를 사용하면 레코드당 1바이트가 저장된다.
1억 개의 레코드를 가지고 있다면, 100MB를 절약할 수 있다.
그것이 상당한 양의 디스크 공간이었던 시절이 있었다.

The difference could also be significant if you're running up against the size limit for database rows.
The text of *TEXT data is stored in files external to the table data, so it doesn't count against the limit, but I believe the size field is in the table so it does count.
데이터베이스 행의 크기 제한에 따라 차이가 클 수도 있다.
*TEXT data의 텍스트는 테이블 데이터 외부의 파일에 저장되기 때문에 한계에 반하는 것은 아니지만, 나는 테이블 안에 크기 필드가 있기 때문에 셀 수 있다고 생각한다.

But if neither of these is an issue, go ahead and use the largest type, to future-proof your
하지만 이 두 가지가 모두 문제가 되지 않는다면, 미래에 대비할 수 있도록 가장 큰 유형을 사용하십시오.

2. 결론

longtext 형 사용해도 된다.

다만 text형을 선언한다는 것 자체가 varchar(4000) 이상(default page size = 16K 일경우)의 문자를 사용하겠다는 의미라서 컬럼이 무지 크다는 것은 항상 생각하고 있어야 한다.

-> default page size 에 따라서 varchar 선언할 수 있는 사이즈가 달라진다. DB를 구축할 때부터 검토해야하며

한번 선언한 size는 바꾸기 매우 어렵다. ssd 파티션 튜닝할 때 4K로 해보려다 고생한 기억이 있다;

varchar형에서 사용했던 like 검색을 대체할 인덱스(fulltext, ngram parser, 스핑크스, 엘라스틱서치..등등) 선언은 반드시 필요하고,

서브쿼리로 longtext가 있는 테이블을 사용을 지양해야하며,

JOIN을 쓴다면 인덱스 스캔여부를 확인하고, longtext 형 컬럼을 굳이 쓰지 않아도 된다면

left(컬럼,10) 등으로 잘라서 가져오는 것이 DB에 부하를 줄일 수 있다는 것까지 확인하였다.

끝~

참조 : https://stackoverflow.com/questions/58225898/mysql-is-there-a-lack-of-performance-by-using-longtext-instead-of-mediumtext