MySQL 사이에 사용자 간 메시지를 기록하는 메시지 테이블이 있습니다. 일반적인 ID 및 메시지 유형 (모든 정수 유형) 외에도 실제 메시지 텍스트를 VARCHAR 또는 TEXT로 저장해야합니다. 프런트 엔드 제한을 3000 자로 설정하여 메시지가이 길이보다 오래 db에 삽입되지 않음을 의미합니다.
VARCHAR (3000) 또는 TEXT와 관련하여 근거가 있습니까? VARCHAR (3000)을 작성하는 것에는 다소 반 직관적 인 느낌이 듭니다. Stack Overflow에서 다른 유사한 게시물을 겪었지만이 유형의 일반적인 메시지 저장과 관련된보기를 얻는 것이 좋습니다.
답변
-
TEXT하고BLOB있다 하여 테이블은 단지 실제 저장 영역의 위치에 대한 포인터를 갖는 테이블 떨어져 저장된다. 저장되는 위치는 데이터 크기, 열 크기, row_format 및 MySQL 버전과 같은 많은 요소에 따라 다릅니다. -
VARCHAR테이블과 함께 인라인으로 저장됩니다.VARCHAR크기가 합리적 일 때 더 빠르며, 그와의 상충 관계는 데이터와 하드웨어에 따라 다르므로 데이터와 실제 시나리오를 벤치마킹하고 싶을 것입니다.
답변
사용자 입력 시간을 예측할 수 있습니까?
바차 (X)
사례 : 사용자 이름, 이메일, 국가, 제목, 비밀번호
본문
사례 : 메시지, 이메일, 댓글, 형식이 지정된 텍스트, HTML, 코드, 이미지, 링크
중간 텍스트
사례 : 큰 JSON 본문, 중소형 도서, CSV 문자열
긴 텍스트
사례 : 교과서, 프로그램, 수년간의 로그 파일, 해리 포터 및 불의 잔, 과학 연구 로깅
답변
모범 사례를 명확히하기 위해 :
-
텍스트 형식 메시지는 거의 항상 TEXT로 저장해야합니다 (임의로 길다).
-
문자열 속성은 VARCHAR (대상 사용자 이름, 주제 등)로 저장해야합니다.
프런트 엔드 한도가 있으며, 그렇지 않을 때까지는 좋습니다. * grin * 트릭은 DB를 연결된 애플리케이션과 분리 된 것으로 생각하는 것입니다. 한 응용 프로그램이 데이터를 제한한다고해서 데이터가 본질적으로 제한되어있는 것은 아닙니다.
메시지 자체가 3000자를 넘지 않도록하는 것은 무엇입니까? 임의의 응용 프로그램 제약 조건 (예 : 텍스트 상자 등) 인 경우 TEXT데이터 영역에서 필드를 사용하십시오 .
답변
면책 조항 : 나는 MySQL 전문가가 아니지만 …이 문제에 대한 나의 이해입니다.
TEXT는 mysql 행 외부에 저장되어 있지만 VARCHAR은 행의 일부로 저장되어 있다고 생각합니다. mysql 행의 최대 행 길이가 있습니다. 따라서 VARCHAR을 사용하여 행에 저장할 수있는 다른 데이터의 양을 제한 할 수 있습니다.
또한 VARCHAR이 행의 일부를 형성하기 때문에 해당 필드를 보는 쿼리가 TEXT 청크를 사용하는 쿼리보다 약간 빠를 것이라고 생각합니다.
답변
짧은 대답 : 실제, 성능 또는 스토리지 차이가 없습니다.
긴 대답 :
본질적으로 VARCHAR(3000)(와 다른 큰 한계)와 ( MySQL에서) 차이는 없습니다 TEXT. 전자는 3000 자 에서 잘립니다 . 후자는 65535 바이트 에서 잘립니다. . ( 문자가 여러 바이트를 취할 수 있기 때문에 바이트 와 문자를 구별 합니다.)
의 한계가 작을수록 VARCHAR몇 가지 장점이 TEXT있습니다.
- “작게”는 버전, 컨텍스트 및에 따라 191, 255, 512, 767 또는 3072 등을 의미
CHARACTER SET합니다. INDEXes열을 색인 할 수있는 크기가 제한됩니다. (767 또는 3072 바이트 ; 버전 및 설정에 따라 다름)- 컴플렉스에서 생성 된 중간 테이블
SELECTs은 MEMORY (빠른) 또는 MyISAM (느린)의 두 가지 방식으로 처리됩니다. ‘큰’열이 관련되면 느린 기술이 자동으로 선택됩니다. (버전 8.0에서는 중요한 변경 사항이 있으므로이 글 머리 기호 항목은 변경 될 수 있습니다.) - 이전 항목과 관련하여 모든
TEXT데이터 유형 (과 반대로VARCHAR)은 MyISAM으로 바로 이동합니다. 즉,TINYTEXT생성 된 임시 테이블의 경우 해당 테이블보다 자동으로 더 나쁩니다VARCHAR. (그러나 이것은 세 번째 방향으로 토론을합니다!) VARBINARY같다VARCHAR;BLOB같다TEXT.
다른 답변에 대한 반박
원래의 질문은 한 가지 (사용할 데이터 유형)를 물었습니다. 허용 된 답변은 다른 것 (비 레코드 저장)에 대답했습니다. 그 대답은 이제 구식입니다.
이 스레드가 시작 되고 응답 되었을 때 InnoDB에는 두 개의 “행 형식”만있었습니다. 빨리 이후에, 두 개 더 형식 ( DYNAMIC및COMPRESSED )이 추가되었습니다.
의 저장 위치 TEXT와는 VARCHAR()기반으로 크기 여부에, 데이터 형의 이름 . 큰 텍스트 / 블럼 열의 온 / 오프 레코드 저장에 대한 업데이트 된 설명은 이 내용을 참조 하십시오 .
답변
위의 답변은 주요 문제를 충분히 주장하지 않습니다.
(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id) 임시 테이블이 필요할 수 있으며 VARCHAR필드가 관련된 CHAR경우 임시 테이블 의 필드 로 변환됩니다 . 따라서 테이블에 VARCHAR(65000)필드 가있는 500,000 줄이라고 말하면 이 열만 6.5 * 5 * 10 ^ 9를 사용합니다 바이트를 사용합니다. 이러한 임시 테이블은 메모리에서 처리 할 수 없으며 디스크에 기록됩니다. 그 영향은 치명적일 수 있습니다.
(메트릭) 자료 : https://nicj.net/mysql-text-vs-varchar-performance/
(이 취급을 말한다 TEXT대 VARCHAR“표준”()의 MyISAM 스토리지 엔진에 그것은 다른 사람과 다를 수 있습니다,?. 예 : InnoDB)
답변
VARCHAR과 TEXT 사이 에는 큰 차이가 있습니다. VARCHAR 필드는 색인화 될 수 있지만 TEXT 필드는 색인화 할 수 없습니다. VARCHAR 유형 필드는 인라인으로 저장되는 반면 TEXT는 오프라인으로 저장되며 TEXT 데이터에 대한 포인터 만 실제로 레코드에 저장됩니다.
VARCHAR보다 더 빠른 검색을 위해 필드를 색인화해야하는 경우, VARCHAR보다 아무리 크더라도 업데이트 또는 삭제하십시오. VARCHAR (10000000)은이 두 데이터 유형이 본질적으로 다르기 때문에 TEXT 필드와 절대 동일하지 않습니다.
- 보관 용도로만 필드를 사용하는 경우
- 데이터 속도 검색에 신경 쓰지 않습니다
- 속도에 관심이 있지만 검색어에 연산자 ‘% LIKE %’를 사용하므로 색인 생성에 큰 도움이되지 않습니다.
- 데이터 길이의 한계를 예측할 수 없습니다
TEXT보다
