MySQL VARCHAR 길이 및 UTF-8


84

MySQL VARCHAR(32)에서 UTF-8 테이블에 새 필드를 만들면 해당 필드에 32 바이트의 데이터를 저장할 수 있는지 아니면 32 자 (멀티 바이트)를 저장할 수 있습니까?


@naXa :하지 않았습니다. 내가해야한다고 생각하세요?
Alix Axel 2014 년

모르겠습니다.) 귀하의 질문이며 귀하에게 달려 있습니다. "다른 답변이 더 완전 해 보입니다"라고 말하고 싶었습니다.
naXa 2014 년

@robsch 이전에 받아 들여진 대답은 간단하고 정확했습니다. 그러나 대중의 요구에 따라 나는 당신이 원하는 것을 받아 들였습니다.
Alix Axel 2015 년

답변:


168

이 답변은 내 Google 검색 결과 상단에 표시되었지만 정확하지 않았습니다.

혼란은 아마도 다른 버전의 mysql이 테스트되기 때문일 것입니다.

  • 버전 4는 바이트를 계산합니다.
  • 버전 5는 문자를 계산합니다.

http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html

MySQL은 문자 열 정의의 길이 사양을 문자 단위로 해석합니다. (MySQL 4.1 이전에는 열 길이가 바이트로 해석되었습니다.) 이는 CHAR, VARCHAR 및 TEXT 유형에 적용됩니다.

흥미롭게도 (나는 그것에 대해 생각하지 않았다) varchar 열의 최대 길이는 다음과 같이 utf8의 영향을받습니다.

MySQL 5.0.3 이상에서 VARCHAR의 유효 최대 길이는 최대 행 크기 (65,535 바이트, 모든 열에서 공유 됨) 및 사용 된 문자 집합의 영향을받습니다. 예를 들어, utf8 문자는 문자 당 최대 3 바이트를 요구할 수 있으므로 utf8 문자 세트를 사용하는 VARCHAR 열은 최대 21,844 자로 선언 될 수 있습니다.


48
M 브라운, 언급 해주셔서 감사합니다. VARCHAR (10) 필드 (사용 utf8mb4)는 "💩💩💩💩💩💩💩💩💩💩"(10 개의 똥 더미)를 저장할 수 있습니다. 즉, 10 자이지만 40 바이트입니다.
basic6

3
이. 이것이 유일한 정답입니다. 너무 많은 사람들이 버전 4의 행동을 복음으로 믿습니다.
Brendan Byrd

2
받아 들여진 대답은 MySQL 5에서도 정확합니다. 삽입 된 숫자는 실제로 전폭 문자 집합의 일부였으며 "32 멀티 바이트 데이터"를 삽입 한 포스터에서도 언급했듯이 멀티 바이트 유니 코드 문자입니다. 많은 사람들이 오해 한 것은 부끄러운 일입니다.
user193130

다음 소스를 인용하면 utf8 문자에는 현재 최대 6 바이트가 필요하므로 1 ~ 6 바이트 사이의 어느 곳에서나 필요합니다. 이로 인해 문자 최대 값이 10922가되는 최악의 경우가 발생합니다. joelonsoftware.com/articles/Unicode.html
usumoio

1
@usumoio 현재 MySQL은 UTF-8의 3 바이트 변형을 사용하고 있으며 (표준) 4 바이트 변형으로 마이그레이션 할 계획입니다. dev.mysql.com/doc/refman/8.0/en/charset-unicode -utf8.html .
flow2k

8

32 개의 멀티 바이트 문자를 저장할 수 있습니다.

UTF-8로 공간을 절약하려면 CHAR 대신 VARCHAR을 사용하십시오. 그렇지 않으면 MySQL은 가능한 최대 길이이므로 CHAR CHARACTER SET utf8 열의 각 문자에 대해 3 바이트를 예약해야합니다. 예를 들어 MySQL은 CHAR (10) CHARACTER SET utf8 열에 대해 30 바이트를 예약해야합니다.

http://dev.mysql.com/doc/refman/5.0/en/charset-unicode.html


나는 거의 사용하지 않으며 CHAR할 때 멀티 바이트 문자를 저장하는 것이 아니므로 안전합니다. 무엇에 대해 VARCHAR, 반드시 제한이 단일 바이트 문자에 멀티 바이트 문자에 정의되지 않고있어?
Alix Axel

9
@jspcal : UTF-8은 3이 아닌 문자 당 최대 4 바이트를 사용합니다. 아니면 MySQL이 4 바이트를 모두 지원하지 않습니까?
Remy Lebeau

5
@RemyLebeau 당신은 utf8에 대해 옳지 만 MySQL은 아닙니다. 다양한 utf8_xxx 문자 세트는 최대 3 바이트입니다. utf8mb4_xxx는 4 바이트 문자를 사용합니다. dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html
Buttle Butkus

시간이 지남에 따라 MySQL은 마침내 표준 4 바이트 버전을 사용하는 것처럼 보입니다 (작성 당시에는 아직 아님) : dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8 .html .
flow2k

6

collation과 함께 32 멀티 바이트 데이터 , 방금 XAMPP로 테스트했습니다.varchar(32)utf8_unicode_ci

1234567890123456789012345678901234567890

다음으로 잘립니다.

12345678901234567890123456789012

이들은 일반 ASCII 문자가 아님을 명심하십시오.


4
UTF-8에서 표준 ASCII 문자는 단일 바이트로만 저장됩니다. 실제로 이것을 테스트하려면 테스트 스팅에서 실제로 멀티 바이트 (즉, 비 ASCII) 문자를 사용해야합니다.
rjmackay 2013

5
이것은 적어도 MySQL 5+에서는 잘못되었습니다. varchar 또는 char에 대한 열 크기를 지정할 때 문자 단위로 지정됩니다. VARCHAR (32) 열의 실제 크기는 32x3 + 1 = 97 바이트라고 생각합니다.
Buttle Butkus 2013 년

5
@rjmackay '12345'는 표준 ASCII 문자가 아닙니다. en.wikipedia.org/wiki/...
알렉세이 레베 데프에게

7
40 개의 유니 코드 문자를 DB에 삽입하고 32 자에서 잘 렸습니다. 그러나 사람들은 내가 ascii 바이트를 사용하고 32 바이트에서 잘린 것으로 생각하는 것처럼 보입니다. 당연히, 나는 반대표를 얻었습니다.
YOU

2
@ButtleButkus "VARCHAR (32) 열의 실제 크기는 32x3 + 1 = 97 바이트라고 생각합니다."를 사용 utf8하면 MySQL에서 유니 코드 지원이 중단됩니다. utf8mb4대신 인코딩을 사용해야합니다 . MySQL의 utf8 변형에서와 같이 3이 아닌 utf-8 char에서 4 바이트 ...
Stijn de Witt

1

행의 총 데이터 길이가 고정되고 빠르기 때문에 자주 업데이트되는 테이블에는 "char"를 사용하는 것이 좋습니다. Varchar 열은 행 데이터 크기를 동적으로 만듭니다. 그것은 MyISAM에 좋지 않지만 InnoDB와 다른 사람들에 대해서는 모릅니다. 예를 들어, 매우 좁은 "유형"열이있는 경우 최소 공간 만 요구하려면 latin1 문자 집합과 함께 char (2)를 사용하는 것이 좋습니다.


1
나는 테이블의 열이 varchar이면 char 열을 갖는 모든 이점을 잃는다는 것을 읽었습니다. 기본적으로 최대한의 이점을 얻으려면 테이블의 모든 varchar 또는 모든 char을 사용해야하는 것 같습니다. 그래도 사실인지 모르겠습니다.
Buttle Butkus 2013 년

의 MyISAM의 경우가 일부 에 대한 인수 CHAR. InnoDB의 경우, "동적 / 고정 된 행 크기"논쟁이 본질적으로 관련이 없을 정도로 많은 다른 일이 진행되고 있습니다.
Rick James

IMHO 여기서 중요한 점은 매우 작은 길이의 경우 CHAR.
ToolmakerSteve

0

latin1 인코딩 (예 : PHP 사용)을 사용하여 데이터베이스에 연결하여 MySQL UTF8 열에 PHP UTF8 문자열을 저장하면 이중 UTF8 인코딩이됩니다.

UTF8 문자열의 $s길이가 32 자이지만 길이가 64 바이트이고 열이 VARCHAR(32)UTF8 인 경우 이중 인코딩은 문자열 $s을 64 자 길이의 UTF8 문자열 로 변환 하여 데이터베이스에서 잘리는 첫 번째 32 바이트에 해당하는 32 자 문자열로 변환합니다. / $s. MySQL 5가 MySQL 4처럼 작동한다고 생각할 수도 있지만 실제로는 동일한 효과의 두 번째 원인입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.