고성능 MySql의 진화(2): 데이터 유형의 최적화_2부

· BLOB/TEXT
실제 애플리케이션에서는 두 가지 유형의 더 큰 데이터를 저장해야 하는 경우가 많습니다. 하나는 더 큰 바이너리 데이터(예: 10M 사진)이고 다른 하나는 더 큰 텍스트(예: 수만 개)입니다. 단어의. Oracle에는 이 두 가지 유형의 데이터를 처리하기 위해 BOLB와 CLOB가 있는 반면, MySQL에서는 BLOB와 TEXT에 해당합니다.
이 두 가지 데이터 유형의 특수성을 고려하여 BLOB와 TEXT의 저장 및 작동은 다음과 같습니다. MySQL에서 수행되는 특수 처리:
1) BLOB/TEXT 값은 종종 객체로 처리됩니다. 이러한 객체는 고유한 ID와 독립적인 저장 공간을 갖습니다.
2) BLOB/TEXT 값을 정렬에 사용하는 경우 , 처음 N 바이트만 사용됩니다. N은 데이터베이스의 상수 값(max_sort_length)에 해당합니다. 정렬에 사용할 더 많은 바이트를 지정하려면 max_sort_length 값을 늘리거나 ORDER BY SUBSTRING(
3) BLOB/TEXT를 인덱싱이나 정렬에 사용할 경우 전체 필드의 값을 사용할 수 없습니다.
BOLB/TEXT를 인덱싱이나 정렬에 최후의 수단으로 사용하지 마세요

MySQL의 메모리 엔진은 BLOB 및 TEXT 유형을 지원하지 않기 때문에 쿼리 프로세스에 BLOB/TEXT가 포함된 경우 데이터 행이 몇 개만 있어도 MyISAM 디스크 임시 테이블을 사용해야 합니다. true(최신 Percona Server의 메모리 엔진은 BLOB 및 TEXT 유형을 지원합니다).

메모리 엔진이 디스크 임시 테이블에 자주 액세스하면 심각한 성능 오버헤드가 발생하므로 BLOB 및 TEXT 유형을 최대한 사용하지 않는 것이 좋습니다. 이를 피할 수 없는 경우 BLOB 필드가 열 값을 문자열로 변환하는 데 사용되는 모든 곳에서 SUBSTRING(열, 길이)을 사용하는 것이 트릭입니다(ORDER BY 절에서도 작동함). -메모리 임시 테이블. 그러나 임시 테이블의 크기가 max_heap_table_size 또는 tmp_table_size를 초과하지 않도록 차단된 하위 문자열이 충분히 짧은지 확인하십시오. 제한을 초과한 후 MySQL은 메모리 임시 테이블을 MyISAM 디스크 임시 테이블로 변환합니다.

최악의 길이 할당은 정렬에서도 동일하므로 이 트릭은 메모리에 대용량 임시 테이블 생성 및 파일 정렬, 디스크 및 파일에 대용량 임시 테이블 생성에 유용합니다. 정렬은 두 경우 모두에 도움이 됩니다. 예를 들어, 몇 기가바이트의 디스크 공간을 차지하는 천만 행 테이블이 있다고 가정합니다. utf8 문자 집합이 있는 VARCHAR(1000) 열이 있습니다. 각 문자는 최대 3바이트를 사용하며 최악의 경우 3,000바이트의 공간이 필요합니다. 이 열이 ORDER BY에 사용되고 쿼리가 전체 테이블을 스캔하는 경우

·     DATETIME/TIMESTAMP
정렬을 위해 30GB 이상의 임시 테이블이 필요합니다. MySQL에는 DATETIME 및 TIMESTAMP의 두 가지 시간 형식이 포함되어 있습니다. 일반적으로 두 타입의 사용시에는 큰 차이는 없으나, 그래도 디테일에서는 차이가 있습니다

TMESSSTAMP는 저장공간을 덜 차지하기 때문에 활용도가 높은 역할을 합니다. 기본 시간 형식

· ENUM
이 유형의 필드는 사용 과정에 관여하기 때문에 주로 열거를 통해 열 값을 저장합니다. 열거 위치와 실제 값은 전체 성능에 일정한 영향을 미칠 수 있으며 열거 값은 .frm(데이터 테이블 구조 정의 파일)에 저장되므로 ENUM 열이 생성된 후 EMUM은 테이블 구조를 업데이트하는 것과 같습니다.
다음은 ENUM 열 생성의 간단한 예입니다.

mysql> CREATE TABLEenum_test(
->  e ENUM('fish', 'apple', 'dog') NOT NULL
-> );
mysql> INSERT INTOenum_test(e) VALUES('fish'), ('dog'), ('apple');

·                                                                                                                    BIT 최소한의 양을 차지하도록 어떻게 디자인하시겠습니까? 공간? INT 또는 CHAR(1)을 사용하시겠습니까? INT 및 CHAR(1)에 비해 BIT(1)은 하나의 BIT만 차지하므로 더 나은 선택일 수 있습니다. 여러 BIT의 값을 BIT(N) 형태로 표현할 수 있으며, 최대 BIT(64)까지 지원한다.

MySQL 5.0 이전 버전에서는 BIT가 TINYINT와 동일한 것으로 간주되었지만 새 버전에서는 완전히 다른 두 가지 유형으로 취급됩니다.

데이터베이스에서 BIT 필드를 검색하여 콘솔에 표시하면 해당 값이 ASCII 인코딩으로 표시됩니다. 필드 값이 숫자 연산의 맥락에서 나타나면 처리됩니다. 다음 예는 이 두 가지 상황을 명확하게 보여줍니다.

mysql>CREATE TABLE bittest(a bit(8));
mysql> INSERT INTObittest VALUES(b'00111001');
mysql> SELECT a, a+ 0 FROM bittest;
+------+-------+
| a | a + 0 |
+------+-------+
| 9 | 57 |
+------+-------+

위의 예는 혼란스러울 수 있으며 더 이상 이 메커니즘을 사용하지 않을 가능성이 높습니다. bit, 대안으로 해당 필드를 CHAR(0)으로 설정할 수 있으며, NULL은 False를 나타냅니다. ""(빈 문자열)은 True를 나타냅니다

위는 고성능 MySql( 2) :데이터 유형 최적화_ 아래의 내용, 더 많은 관련 내용을 보려면 PHP 중국어 웹사이트(www.php.cn)를 참고하세요!