>  기사  >  데이터 베이스  >  MySQL의 데이터 유형에 대한 포괄적인 이해

MySQL의 데이터 유형에 대한 포괄적인 이해

怪我咯
怪我咯원래의
2017-03-30 11:32:431453검색

1. Char 및 varchar 유형

Char와 varchar 유형은 유사합니다. 둘 다 문자열을 저장하는 데 사용되지만 문자열을 저장하고 검색하는 방식이 다릅니다. char은 고정 길이 문자 유형 에 속하고, varchar는 가변 길이 문자 유형에 속합니다. 예를 들어, char(4) 및 varchar(4)의 두 가지 유형 정의의 경우:

(1), ''는 char(4)에서 4바이트를 차지하며, varchar(4)에서는 1바이트만 차지합니다. length;

(2), 'ab'는 char(4)에서 4바이트를 차지하고 varchar(4)에서는 3바이트만 차지합니다.

(3), 'abcd'는 4를 차지합니다. char(4)에는 바이트, varchar(4)에는 5바이트 ​​

varchar 유형에 추가 바이트 길이가 있는 이유는 무엇입니까? 이는 varchar 유형이 추가 바이트를 사용하여 varchar 유형의 실제 길이를 저장하기 때문입니다. char(4) 및 varchar(4) 검색이 항상 동일하지는 않습니다. 예:

mysql> create table char_and_varchar (v varchar(4),c char(4));
Query OK, 0 rows affected (0.20 sec)

mysql> insert into char_and_varchar values ('ab  ','ab  ');
Query OK, 1 row affected (0.33 sec)

mysql> select concat(v,'cd'),concat(c,'cd') from char_and_varchar;
+----------------+----------------+
| concat(v,'cd') | concat(c,'cd') |
+----------------+----------------+
| ab  cd         | abcd           |
+----------------+----------------+
1 row in set (0.35 sec)


char는 고정 길이이므로 처리 속도가 varchar보다 훨씬 빠릅니다. 하지만 저장 공간이 낭비된다는 단점이 있고, 프로그램이 후행 공백을 처리해야 하기 때문에 길이가 많이 변하지 않고 쿼리 속도에 대한 요구 사항이 높은 데이터는 char 형식을 사용하여 저장하는 것을 고려할 수 있습니다. MySQL 버전이 계속 업그레이드됨에 따라 varchar데이터 유형의 성능도 지속적으로 향상될 것이며, varchar 유형의 적용 범위는 더욱 넓어질 것입니다.

MySQL에서는 다양한 스토리지 엔진마다 char 및 varchar에 대한 사용 원칙이 다릅니다.

(1) MyISAM 스토리지 엔진에서는 변수 대신 고정 길이 필드 유형을 사용하는 것이 좋습니다. 가변 길이 필드 유형.
(2) 메모리 저장 엔진에는 현재 고정 길이의 데이터 라인이 저장되어 있으므로 char 유형이든 varchar 유형이든 char 유형으로 변환하여 처리합니다.
(3) InnoDB 스토리지 엔진에서는 varchar 유형을 사용하는 것이 좋습니다.

2. TEXT 및 BLOB

소량의 문자열을 저장할 때는 char 및 varchar 데이터 유형을 사용할 수 있습니다. 더 큰 텍스트를 저장할 때는 일반적으로 텍스트나 BLOB를 사용하도록 선택합니다. 둘 사이의 가장 큰 차이점은 BLOB는 사진과 같은 바이너리 데이터를 저장하는 데 사용할 수 있는 반면 텍스트는 문자 형식의 데이터를 저장하는 데만 사용할 수 있다는 것입니다. Text 및 BLOB에는 각각 text, Mediumtext, Longtext 및 Blob, Mediumblob 및 Longblob의 세 가지 유형이 포함됩니다. 이들 간의 주요 차이점은 저장된 텍스트 길이와 저장된 바이트 수입니다.

BLOB 및 TEXT 유형을 사용할 때 주의해야 할 몇 가지 문제:

(1), BLOB 및 TEXT는 특히 대량의 삭제 작업을 수행할 때 성능 문제를 일으킬 수 있습니다. . 삭제 작업은 데이터 테이블에 큰 "구멍"을 남깁니다. 나중에 이러한 "구멍" 레코드를 채우면 삽입 성능에 영향을 미칩니다. 성능을 향상시키려면 정기적으로 OPTIMIZETABLE 함수를 사용하여 이러한 테이블의 조각 모음을 수행하여 성능 문제를 일으키는 구멍을 방지해야 합니다.

(2) 합성 인덱스를 사용하여 큰 텍스트 필드의 쿼리 성능을 향상시킵니다. 소위 합성 인덱스는 큰 텍스트 필드의 내용을 기반으로 해시 값을 생성하고 이 값을 별도의 데이터 열에 저장한 다음 해시 값을 통해 데이터 행을 찾을 수 있습니다. 예:

mysql> create table t (id varchar(100),content blob,hash_value varchar(40));
Query OK, 0 rows affected (0.03 sec)

mysql> insert into t values (1,repeat('beijing',2),md5(content)); 
Query OK, 1 row affected (0.33 sec)

mysql> insert into t values (2,repeat('beijing',2),md5(content)); 
Query OK, 1 row affected (0.01 sec)

mysql> insert into t values (2,repeat('beijing 2008',2),md5(content));
Query OK, 1 row affected (0.01 sec)

mysql> select * from t;
+------+--------------------------+----------------------------------+
| id   | content                  | hash_value                       |
+------+--------------------------+----------------------------------+
| 1    | beijingbeijing           | 09746eef633dbbccb7997dfd795cff17 |
| 2    | beijingbeijing           | 09746eef633dbbccb7997dfd795cff17 |
| 2    | beijing 2008beijing 2008 | 1c0ddb82cca9ed63e1cacbddd3f74082 |
+------+--------------------------+----------------------------------+
3 rows in set (0.00 sec)

mysql> select * from t where hash_value=md5(repeat('beijing 2008',2));
+------+--------------------------+----------------------------------+
| id   | content                  | hash_value                       |
+------+--------------------------+----------------------------------+
| 2    | beijing 2008beijing 2008 | 1c0ddb82cca9ed63e1cacbddd3f74082 |
+------+--------------------------+----------------------------------+
1 row in set (0.00 sec)


합성 인덱스는 완전 일치 시나리오에서만 사용할 수 있으므로 디스크 I/O가 어느 정도 줄어들고 쿼리 효율성이 향상됩니다. BLOB 및 CLOB 필드에 대해 퍼지 쿼리를 수행해야 하는 경우 MySQL의 접두사 인덱스를 사용할 수 있습니다. 즉, 필드의 처음 n 열에 대한 인덱스를 생성할 수 있습니다. 예:

mysql> create index idx_blob on t (content(100));
Query OK, 0 rows affected (0.09 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show index from t \G
*************************** 1. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_blob
 Seq_in_index: 1
  Column_name: content
    Collation: A
  Cardinality: 3
     Sub_part: 100
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment: 
Index_comment: 
1 row in set (0.00 sec)

mysql> desc select * from t where content like 'beijing%' \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: ALL
possible_keys: idx_blob
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 3
        Extra: Using where
1 row in set (0.00 sec)

(3). 필요한 경우가 아니면 큰 BLOB 또는 TEXT 필드를 검색하지 마세요.

(4) BLOB 또는 TEXT 필드를 별도의 테이블로 분리합니다.

3. 부동 소수점 숫자와 고정 소수점 숫자

부동 소수점 숫자는 일반적으로 소수 부분을 포함하는 값을 나타내는 데 사용됩니다. 필드가 부동 소수점 유형으로 정의된 경우 삽입된 데이터의 정밀도가 열에 정의된 실제 정밀도를 초과하는 경우 삽입된 값은 실제 정의된 정밀도로 반올림됩니다. 값을 삽입하면 반올림 프로세스에서 오류가 보고되지 않습니다. MySQL의 Float 및 Double(실수)은 부동 소수점 숫자를 나타내는 데 사용됩니다.

고정 소수점 수는 부동 소수점 수와 다릅니다. 고정 소수점 수는 실제로 문자열 형태로 저장되므로 고정 소수점 수는 데이터를 더 정확하게 저장할 수 있습니다. 삽입된 데이터의 정밀도가 실제 정의된 정밀도보다 크면 MySQL은 경고를 표시하지만 데이터는 삽입되기 전에 실제 정밀도로 반올림됩니다(기존 모드로 삽입된 경우 오류가 보고됩니다). MySQL에서는 고정 소수점 숫자를 나타내는 데 십진수(또는 숫자)가 사용됩니다.

부동 소수점 숫자를 사용하여 데이터를 저장하면 오류가 발생합니다(예: 통화). 고정 소수점 숫자를 사용하여 데이터를 저장해야 합니다. 예:

mysql> create table b (c1 float(10,2),c2 decimal(10,2));
Query OK, 0 rows affected (0.37 sec)

mysql> insert into b values (131072.32,131072.32);
Query OK, 1 row affected (0.00 sec)

mysql> select * from b;
+-----------+-----------+
| c1        | c2        |
+-----------+-----------+
| 131072.31 | 131072.32 |
+-----------+-----------+
1 row in set (0.00 sec)

四、日期类型

MySQL提供的常用的日期类型有:date、time、datetime、timestamp,日期类型的选用原则:

(1)、应根据实际需要选择能够满足应用的最小存储的日期类型;

(2)、如果要记录年月日时分秒,且年代比较久远,最好使用datetime类型;

(3)、如果记录的日期要被多时区的用户所使用,那么最好使用timestamp类型。


위 내용은 MySQL의 데이터 유형에 대한 포괄적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.