10.5.1 Optimizing Storage Layout for InnoDB Tables

10.5.1 InnoDB 테이블의 스토리지 레이아웃 최적화

• 데이터 크기가 안정된 상태에 도달했거나, 증가 중인 테이블의 크기가 수십 또는 수백 메가바이트 단위로 커진 경우, OPTIMIZE TABLE 문을 사용하여 테이블을 재구성하고 낭비된 공간을 압축하는 것을 고려하십시오. 재구성된 테이블은 전체 테이블 스캔을 수행할 때 더 적은 디스크 I/O를 필요로 합니다. 이는 인덱스 사용 개선이나 애플리케이션 코드 튜닝 같은 다른 기법들이 실용적이지 않을 때 성능을 향상시킬 수 있는 직접적인 기법입니다.

OPTIMIZE TABLE은 테이블의 데이터 부분을 복사하고 인덱스를 다시 빌드합니다. 이점은 인덱스 내 데이터의 더 향상된 패킹과 테이블스페이스 및 디스크 상의 단편화 감소에서 옵니다. 이점은 각 테이블의 데이터에 따라 달라집니다. 어떤 테이블에서는 상당한 이득을 얻지만 다른 테이블에서는 그렇지 않을 수도 있고, 또는 다음에 테이블을 최적화할 때까지 시간이 지남에 따라 이득이 줄어들 수도 있습니다. 이 작업은 테이블이 크거나 다시 빌드되는 인덱스가 버퍼 풀에 들어가지 못하는 경우에는 느릴 수 있습니다. 테이블에 많은 데이터를 추가한 후 처음 실행할 때가 이후 실행보다 훨씬 느린 경우가 많습니다.

• InnoDB에서 긴 PRIMARY KEY(값이 긴 단일 컬럼이거나, 길이가 긴 복합 값을 이루는 여러 컬럼)는 많은 디스크 공간을 낭비합니다. 한 로우의 primary key 값은 동일한 로우를 가리키는 모든 세컨더리 인덱스 레코드에 복제됩니다. (Section 17.6.2.1, “Clustered and Secondary Indexes” 참조.) primary key가 길다면 AUTO_INCREMENT 컬럼을 primary key로 생성하거나, 전체 컬럼 대신 길이가 긴 VARCHAR 컬럼의 프리픽스에 인덱스를 생성하십시오.

• 가변 길이 문자열을 저장하거나 NULL 값이 많은 컬럼에는 VARCHAR 데이터 타입을 CHAR 대신 사용하십시오. CHAR(N) 컬럼은 문자열이 더 짧거나 값이 NULL인 경우에도 항상 데이터를 저장하는 데 N 문자를 사용합니다. 더 작은 테이블은 버퍼 풀에 더 잘 맞고 디스크 I/O를 줄여 줍니다.

COMPACT 로우 포맷과 utf8mb4 또는 sjis와 같은 가변 길이 문자 집합을 사용할 때, CHAR(N) 컬럼은 가변적인 양의 공간을 차지하지만, 여전히 최소 N 바이트를 사용합니다.

• 크기가 크거나 반복적인 텍스트 또는 숫자 데이터가 많은 테이블에는 COMPRESSED 로우 포맷 사용을 고려하십시오. 데이터를 버퍼 풀로 가져오거나 전체 테이블 스캔을 수행하는 데 필요한 디스크 I/O가 줄어듭니다. 영구적인 결정을 내리기 전에, COMPACT 로우 포맷과 비교하여 COMPRESSED를 사용했을 때 달성할 수 있는 압축량을 측정하십시오.