데이터가 안정된 크기에 도달하거나 확대하는 테이블이 수십 또는 수백 메가 바이트 단위로 증가했을 경우, OPTIMIZE TABLE 문을 사용하여 테이블을 재구성하고 불필요한 공간을 압축하는 것을 고려 합니다. 재구성 된 테이블에서 전체 테이블을 스캔하는 데 필요한 디스크 I / O가 줄어 듭니다. 이것은 인덱스의 사용 개선과 애플리케이션 코드 튜닝 등 다른 기법이 적합하지 않은 경우 성능을 향상시킬 수있는 직접적인 방법입니다.

OPTIMIZE TABLE 은 테이블의 데이터 부분을 복사하여 인덱스를 다시 작성합니다. 인덱스에 데이터 팩의 개선과 테이블 공간 및 디스크 조각화 절감의 혜택을 얻을 수 있습니다. 이 장점은 각 테이블의 데이터에 따라 다릅니다. 장점이 큰 것과 그렇지 않은 것이있다, 또는 테이블의 다음 최적화까지 시간이 지남에 이점이 줄어드는 것을 알 수 있습니다. 이 작업은 테이블이 큰 경우 나 재구성되는 인덱스가 버퍼 풀에 들어 가지 않는 경우 느려질 수 있습니다. 대량의 데이터를 테이블에 추가 한 뒤 첫 실행에서는 많은 경우에 그 실행보다 상당히 느립니다.

InnoDB 는 긴 PRIMARY KEY (긴 값을 가진 단일 컬럼 또는 긴 복합 값을 형성하는 복수의 열 중 하나)가 많은 양의 디스크 공간을 낭비합니다. 행의 기본 키 값은 같은 행에 대한 모든 보조 인덱스 레코드에 복제됩니다. ( 섹션 14.2.13 "InnoDB 테이블 및 인덱스 구조" 를 참조하십시오.) 기본 키가 긴 경우 AUTO_INCREMENT 컬럼을 기본 키로 만들거나 열 전체가 아닌 긴 VARCHAR 컬럼의 프리픽스를 인덱스 설정 합니다.

가변 길이의 문자열을 저장하기 위해, 또는 많은 NULL 값을 가지는 컬럼에 대해 CHAR 대신 VARCHAR 데이터 유형을 사용합니다. CHAR( N ) 컬럼은 스트링이 짧거나 그 값이 NULL 이라고해도 데이터를 저장하는 데 항상 N 문자를 필요로합니다. 테이블이 작을수록 버퍼 풀에 맞는 쉽고, 디스크 I / O가 줄어 듭니다.

COMPACT 행 형식 (MySQL 5.6의 기본 InnoDB 형식)과 utf8 및 sjis 등의 가변 길이 문자 집합을 사용하는 경우, CHAR( N ) 컬럼은 가변 량에서도 역시 N 바이트 이상의 공간을 차지합니다.

크거나 반복적 인 대량의 텍스트와 숫자 데이터를 저장하는 테이블에서는 COMPRESSED 행 형식을 사용하는 것을 고려합니다. 데이터를 버퍼 풀에 넣고, 풀 테이블 스캔을 실행하는 데 필요한 디스크 I / O가 줄어 듭니다. 영구적 인 결정을 내리기 전에 COMPRESSED 과 COMPACT 행 형식을 사용하여 얻을 수있는 압축의 양을 측정합니다.