MySQL5.6 OPTIMIZE TABLE 구문

13.7.2.4 OPTIMIZE TABLE 구문

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE
    tbl_name [, tbl_name] ...

저장 공간을 줄이고 테이블 액세스시의 I / O 효율을 향상시키기 위해 테이블 데이터와 연관된 인덱스 데이터의 물리적 스토리지를 재구성합니다. 각 테이블에 가해지는 정확한 내용은 해당 테이블에 사용되는 스토리지 엔진 에 따라 다릅니다.

OPTIMIZE TABLE 은 테이블의 유형에 따라 다음의 경우에 사용합니다.

innodb_file_per_table 옵션이 활성화 된 상태로 생성 되었기 때문에 자신의 .ibd 파일 을 포함 InnoDB 테이블에 대량 삽입, 업데이트 또는 삭제 작업을 수행 한 후. 테이블과 인덱스가 재구성되기 때문에 디스크 공간을 운영 체제에 의한 사용을 위해 다시 사용할 수 있습니다.
InnoDB 테이블의 FULLTEXT 인덱스의 일부인 컬럼에 대해서 대량의 삽입, 업데이트 또는 삭제 작업을 수행 한 후. 첫째로, 구성 옵션 innodb_optimize_fulltext_only=1 을 설정합니다. 인덱스 유지 관리 기간을 적절한 시간에 유지하기 위해 검색 인덱스에서 업데이트하는 단어 개수를 지정하는 innodb_ft_num_word_optimize 옵션을 설정하고 검색 인덱스가 완전히 업데이트 될 때까지 OPTIMIZE TABLE 문 시퀀스를 실행합니다.
MyISAM 또는 ARCHIVE 테이블의 큰 부분을 삭제하거나 가변 행을 포함 MyISAM 또는 ARCHIVE 테이블 ( VARCHAR , VARBINARY , BLOB 또는 TEXT 컬럼을 포함하는 테이블)에 많은 변경을 행한 뒤에. 삭제 된 행은 링크 목록에 보관되며 이후 INSERT 작업은 이전 행의 위치를 재사용합니다. OPTIMIZE TABLE 을 사용하면 사용되지 않는 공간을 재사용하거나 데이터 파일을 조각 모음 할 수 있습니다. 테이블을 크게 변경 한 후에는이 문은 테이블을 사용하는 명령문의 성능을 (때로는 상당히) 개선 할 수 있습니다.

이 문은이 테이블에 대한 SELECT 및 INSERT 권한이 필요합니다.

OPTIMIZE TABLE 은 파티션 된 테이블에서 지원됩니다. 이 문 파티션 된 테이블에서 사용하거나 테이블 파티션 내용은 섹션 19.3.4 "파티션 관리" 를 참조하십시오.

MySQL 5.6.11에서만이 문을 발행하기 전에 gtid_next 를 AUTOMATIC 으로 설정해야합니다. (Bug # 16062608, Bug # 16715809, Bug # 69045)

OPTIMIZE TABLE 은 InnoDB , MyISAM 및 ARCHIVE 테이블에서 작동합니다. OPTIMIZE TABLE 은 인 메모리 NDB 테이블의 동적 컬럼에 대해서도 지원됩니다. 디스크 데이터 테이블에서 작동하지 않습니다. 클러스터 테이블에 대한 OPTIMIZE 의 성능은 OPTIMIZE TABLE 에 의한 행의 일괄 처리 사이에 대기하는 밀리 세컨드 수를 제어하는 ndb_optimization_delay 시스템 변수의 값을 조정하여 조정할 수 있습니다. 자세한 내용은 섹션 18.1.6.11 "MySQL Cluster NDB 7.3에서 해결 된 이전의 MySQL Cluster 문제" 를 참조하십시오.

MySQL Cluster 테이블의 경우, OPTIMIZE TABLE 은 OPTIMIZE 작업을 실행하는 SQL 스레드를 (예를 들어) 강제 종료하여 중단 할 수 있습니다.

기본적으로 OPTIMIZE TABLE 은 다른 스토리지 엔진을 사용하여 작성된 테이블에 대해서는 작동하지 않고이 지원이 없다는 결과를 반환합니다. --skip-new 옵션을 사용해 mysqld를 시작함으로써 다른 스토리지 엔진에 OPTIMIZE TABLE 을 작동 할 수 있습니다. 이 경우, OPTIMIZE TABLE 은 단순히 ALTER TABLE 에 매핑됩니다.

InnoDB의 정보

InnoDB 테이블의 경우, OPTIMIZE TABLE 은 ALTER TABLE ... FORCE 에 매핑됩니다. 이것은 인덱스 통계를 업데이트하고 클러스터 된 인덱스에서 사용되지 않는 공간을 확보하기 위해 테이블을 재구성합니다. 이것은 다음과 같이 InnoDB 테이블에 대해 실행하면 OPTIMIZE TABLE 의 출력에 표시됩니다.

mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table    | Op       | Msg_type | Msg_text                                                          |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status   | OK                                                                |
+----------+----------+----------+-------------------------------------------------------------------+

Mysql 5.6.17 이전에는 OPTIMIZE TABLE 은 온라인 DDL ( ALGORITHM=INPLACE )를 사용하지 않습니다. 그 결과, OPTIMIZE TABLE 을 실행중인 테이블의 경우 (즉, 테이블 잠금 동안) 병렬 DML ( INSERT , UPDATE , DELETE )이 허용되지 않습니다. 또한 기본 키에 나타나는 순서로 키가 삽입되기 때문에 보조 인덱스는 그만큼 효율적으로 생성되지 않습니다.

5.6.17 시점에서는 OPTIMIZE TABLE 은 InnoDB 의 일반 테이블과 파티션 된 테이블 모두에 대해 온라인 DDL ( ALGORITHM=INPLACE )를 사용합니다. OPTIMIZE TABLE 에 의해 트리거되어 ALTER TABLE ... FORCE 에서 실행되는 테이블 재구성은 현재 온라인 DDL ( ALGORITHM=INPLACE )를 사용하여 수행됩니다 짧 테이블을 잠글하지 않기 때문에 병렬 DML 작업 를위한 다운 타임이 단축됩니다.

OPTIMIZE TABLE 은 계속 다음의 조건 하에서 ALGORITHM=COPY 를 사용합니다.

old_alter_table 시스템 변수가 ON되어있는 경우.
mysqld --skip-new 옵션이 활성화되어있는 경우.

온라인 DDL ( ALGORITHM=INPLACE )를 사용하여 OPTIMIZE TABLE 은 FULLTEXT 인덱스를 포함 InnoDB 테이블에서는 지원되지 않습니다. 대신 ALGORITHM=COPY 를 사용해야합니다.

InnoDB 는 페이지 할당 방법을 사용하여 데이터를 저장하기 위해 기존 스토리지 엔진 ( MyISAM 등)의 경우처럼 조각화가 발생하지 않습니다. 최적화를 실행할지 여부를 검토 할 경우 서버가 처리하는 트랜잭션 워크로드를 고려하십시오.

어느 정도의 조각이 예측됩니다. InnoDB 는 페이지를 분할하지 않아도 업데이트 할 수있는 여지를 남겨 두는 위해 페이지 를 93 %까지만 채우고하지 않습니다.
삭제 작업에 의해 격차가 남겨져 페이지의 여유가 목표보다 많아 질 수 있습니다. 이렇게하면 테이블을 최적화 할 가치가 태어날 가능성이 있습니다.
행을 업데이트하면 일반적으로 충분한 공간이 사용 가능한 데이터 형식 및 행 형식에 따라 같은 페이지의 데이터가 다시 작성됩니다. 섹션 14.7.5 "InnoDB 테이블에서의 압축 동작" 및 섹션 14.9.1 "InnoDB 행 스토리지 개요" 를 참조하십시오.
InnoDB 는 MVCC 메커니즘에 대해 동일한 데이터의 여러 버전을 유지하기 위해 병렬이 높은 워크로드는 시간이 지남에 따라 인덱스에 갭이 남아있을 가능성이 있습니다. 섹션 14.2.12 "InnoDB 멀티 버전" 을 참조하십시오.

MyISAM에 대한 자세한

MyISAM 테이블의 경우, OPTIMIZE TABLE 은 다음과 같이 작동합니다.

테이블 행을 제거하거나 분할 한 경우 해당 테이블을 복구합니다.
인덱스 페이지가 정렬되어 있지 않으면 그것을 정렬합니다.
테이블의 통계가 최신 버전이 아닌 (따라서 인덱스의 정렬에 따라 복구를 수행 할 수없는) 경우, 그것을 갱신합니다.

기타 고려 사항

OPTIMIZE TABLE 은 다음 컬럼을 포함하는 결과 집합을 반환합니다.

컬럼	값
`Table`	테이블 이름
`Op`	항상 `optimize`
`Msg_type`	`status` , `error` , `info` , `note` 또는 `warning`
`Msg_text`	정보 메시지

5.6.17 이전의 InnoDB 테이블 및 기타 테이블 유형의 경우, MySQL은 OPTIMIZE TABLE 을 실행하는 동안 테이블을 잠급니다 . MySQL 5.6.17 시점에서는 OPTIMIZE TABLE 은 InnoDB 의 일반 테이블과 파티션 된 테이블에 대해 온라인으로 실행됩니다.

기본적으로 서버는 OPTIMIZE TABLE 문을 바이너리 로그에 기록하고 또 리플리케이션 슬레이브에 복제되도록합니다. 로깅을하지 않으려면 옵션의 NO_WRITE_TO_BINLOG 키워드 또는 별칭 LOCAL 을 지정합니다.

OPTIMIZE TABLE 은 POINT 컬럼에서 공간 인덱스 등의 R 트리 인덱스를 정렬하지 않습니다. (Bug # 23578)

OPTIMIZE TABLE 테이블은 오래된 파일부터 새롭게 생성 된 파일에 테이블 통계 복사 중에 발생한 모든 오류를 포착하여 발생합니다. 예를 들어, .frm , .MYD 또는 .MYI 파일 소유자의 사용자 ID가 mysqld 프로세스의 사용자 ID와 다를 경우, mysqld가 root 사용자에 의해 실행되고 있지 않은 한, OPTIMIZE TABLE 은 "can not change ownership of the file "오류를 생성합니다.