8.4.1 데이터 크기 최적화
디스크 공간을 최소화하도록 테이블을 설계합니다. 따라서 디스크에 대한 읽기 및 쓰기되는 데이터의 양을 감소시키는 대폭적인 개선을 볼 수 있습니다. 내용이 쿼리 실행 중에 활성화 처리되는 동안 테이블이 작을수록 일반적 필요한 기본 메모리의 양이 줄어 듭니다. 테이블 데이터 영역의 감소에 따라 인덱스도 작아지고 고속으로 처리 할 수 있습니다.
MySQL은 여러 다양한 스토리지 엔진 (테이블 형)과 행 포맷을 지원합니다. 테이블마다 사용하는 스토리지 및 인덱스 구성 방법을 결정할 수 있습니다. 응용 프로그램에 적절한 테이블 형식을 선택함으로써 대폭적인 성능 향상을 얻을 수 있습니다. 제 15 장 "대체 스토리지 엔진" 을 참조하십시오.
여기에서 언급 된 기법을 사용하여 테이블의 성능 개선과 저장 공간의 최소화를 도모 할 수 있습니다.
테이블 컬럼
가능한 가장 효율적인 (최소) 데이터 형식을 사용합니다. MySQL은 디스크 공간과 메모리를 절약하는 많은 전용의 형태가 있습니다. 예를 들어, 가능한 경우는 작은 테이블을 얻기 위해 작은 정수를 사용합니다.
MEDIUMINT
컬럼이 사용하는 공간은 25 % 적기 때문에MEDIUMINT
많은 경우INT
더 적절한 선택입니다.가능한 경우에는 컬럼을
NOT NULL
로 선언합니다. 이에 따라 인덱스를 적절히 사용하여 각 값이NULL
인지 여부를 테스트하기위한 오버 헤드가 없어지는 것으로, SQL 작업이 빨라집니다. 컬럼 당 1 비트에서 약간의 저장 공간을 절약합니다. 테이블에서 실제로NULL
값이 필요한 경우이를 사용합니다. 단순히 모든 컬럼에NULL
값을 허용하는 기본 설정을 피합니다.
행 형식
InnoDB
테이블은 컴팩트 스토리지 포맷을 사용합니다. 5.0.3 이전의 MySQL 버전에서는InnoDB
줄에 고정 된 크기의 컬럼에서도 열 수 및 각 컬럼의 길이 등 일부 중복 정보가 포함됩니다. 기본적으로 테이블은 컴팩트 형식 (ROW_FORMAT=COMPACT
)으로 생성됩니다. MySQL의 이전 버전으로 다운 그레이드하려는 경우ROW_FORMAT=REDUNDANT
에서 오래된 형식을 요청할 수 있습니다.컴팩트 행 형식의 존재에 의해 행의 저장 공간이 약 20 % 감소하지만 일부 작업에서 CPU의 사용이 증가하는 희생을 수반합니다. 워크로드가 캐시 적중률과 디스크 속도에 의해 제한되는 일반적인 워크로드라면 빠를 수 있습니다. CPU 속도에 의해 제한되는 드문 경우는 느려질 수 있습니다.
컴팩트
InnoDB
형식은 UTF-8 데이터를 포함하는CHAR
컬럼이 포함되는 방법도 달라집니다. UTF-8 인코딩 문자의 최대 길이가 3 바이트이기 때문에ROW_FORMAT=REDUNDANT
에서는 UTF-8CHAR(
는 3 ×N
)N
바이트를 차지합니다. 많은 언어는 주로 단일 바이트 UTF-8 문자를 사용하여 쓸 수 있기 때문에 고정 스토리지 길이는 종종 공간을 낭비합니다.ROW_FORMAT=COMPACT
형식은InnoDB
는N
에서 3 ×N
바이트 범위의 스토리지 가변 용량을 필요에 따라 후행 공백을 제거하고이 컬럼에 할당합니다. 최소 스토리지 길이는 일반적인 경우에 적절한 업데이트를 용이하게하는N
바이트로 유지됩니다.테이블 데이터를 압축 형식으로 저장하여 더 많은 공간을 최소화하려면
InnoDB
테이블을 만들 때ROW_FORMAT=COMPRESSED
을 지정하거나 기존의MyISAM
테이블에 대해 myisampack 명령을 실행합니다. (InnoDB
압축 테이블은 읽기 가능 쓰기 가능하지만,MyISAM
압축 테이블은 읽기 전용입니다.)MyISAM
테이블에 가변 길이 컬럼 (VARCHAR
,TEXT
또는BLOB
등)이없는 경우는 고정 크기 행 형식이 사용됩니다. 이것은 빠르지 만 약간 공간을 낭비 할 수 있습니다. 섹션 15.2.3 "MyISAM 테이블 스토리지 포맷" 을 참조하십시오.CREATE TABLE
옵션ROW_FORMAT=FIXED
하여VARCHAR
컬럼이있는 경우에도 고정 길이의 행을 필요로하고 있음을 알 수 있습니다.
인덱스
테이블의 주 인덱스는 가능한 짧게하십시오. 이렇게하면 각 행의 식별을 용이하게 효율적입니다.
InnoDB
테이블의 경우, 프라이 머리 키 컬럼은 각 보조 인덱스 항목에 복제되기 때문에 다수의 보조 인덱스가있는 경우에 짧은 기본 키에 의해 상당한 공간이 절약됩니다.쿼리 성능을 향상시키기 위해 필요한 인덱스만을 만듭니다. 인덱스는 검색에 유용하지만, 삽입 및 업데이트 작업을 느리게합니다. 대부분 열 조합에 대해 검색하여 테이블에 액세스하는 경우, 컬럼에 대해 별도의 인덱스를 만드는 것이 아니라, 그들에 대해 단일 복합 인덱스를 만듭니다. 인덱스의 첫 번째 부분은 가장 많이 사용되는 열해야합니다. 테이블에서 선택하는 경우에 항상 많은 컬럼을 사용하는 경우 적절한 인덱스의 압축을 얻기 위해 인덱스의 첫 번째 컬럼은 가장 중복이 많은 열해야합니다.
긴 문자열 컬럼에서 처음 몇 글자 고유의 프리픽스가있을 가능성이 높은 경우, MySQL의 컬럼의 왼쪽 부분에 대한 인덱싱 지원 ( 섹션 13.1.13 "CREATE INDEX 구문" 을 참조 제발)를 사용하여이 프리픽스에만 인덱스를 설정하는 것이 좋습니다. 짧은 색인수록 빨라지는 것은 필요한 디스크 공간이 부족뿐만 아니라 인덱스 캐시 히트가 많아지고, 그 때문에 디스크 검색이 적어 지므로이기도합니다. 섹션 8.11.2 "서버 파라미터의 튜닝」 을 참조하십시오.
결합
상황에 따라 자주 검색되는 테이블을 2 개로 분할하여 장점이있을 수 있습니다. 이것은 특히 그것이 동적 형식 테이블에서 테이블 스캔시 관련 행을 찾는 데 사용할 수있는 작은 정적 형식 테이블을 사용할 수있는 경우에 적용됩니다.
해당 컬럼에 근거한 빠른 조인을하려면 다른 테이블에서 동일한 정보를 가지는 컬럼을 동일한 데이터 형식으로 선언합니다.
다른 테이블에서 같은 이름을 사용하고 결합 쿼리를 단순화 할 수 있도록 컬럼 이름을 쉽게합니다. 예를 들어,
customer
라는 테이블에서는customer_name
대신name
컬럼 이름을 사용합니다. 이름을 다른 SQL 서버에 이식 할 수 있도록하기 위해 18 자보다 짧게하는 것을 고려합니다.
정규화
일반적으로 모든 데이터를 중복으로 유지하려고합니다 (데이터베이스 이론에서 제 3 정규형라는 것을 준수합니다). 이름이나 주소와 같은 긴 값을 반복하는 대신에 그들에게 고유 ID를 할당 여러 작은 테이블에서 필요한만큼 이러한 ID를 반복 조인 절에서 ID를 참조하여 쿼리에서 테이블을 조인합니다 .
대형 테이블에서 모든 데이터를 분석하는 비즈니스 인텔리전스 시나리오 등으로 디스크 공간이나 데이터의 여러 사본을 유지 보수 비용보다 속도가 더 중요한 경우 정규화 규칙을 완화하여 정보 를 복제하거나 요약 테이블을 만들거나하여 속도를 향상시킬 수 있습니다.