MySQL 5.6 한글메뉴얼

14.11.6 온라인 DDL 구현에 대한 세부 항목

InnoDB 테이블에 대한 각 ALTER TABLE 작업은 다음 몇 가지 측면에 의해 제어됩니다.

테이블의 물리적 표현에 어떤 변화가 있는지, 아니면 순수하게 테이블 자체를 변경하지 않고 실행할 수있는 메타 데이터에 대한 변경인지 여부.
테이블의 데이터의 양이 동일하게 유지하거나 증가하거나 감소하고 있는가?
테이블 데이터의 변경이 클러스터 된 인덱스 보조 인덱스 또는 둘 모두에 관련 있는지.
변경되는 테이블과 다른 테이블 사이에 어떠한 외부 키 관계가 존재하는지 여부. 이 메카닉은 foreign_key_checks 구성 옵션을 활성화 또는 비활성화되어 있는지에 따라 다릅니다.
테이블이 분할되어 있는지. ALTER TABLE 파티션 흘리는는 하나 이상의 테이블에 대한 낮은 수준의 조작으로 변환되어 이러한 작업은 온라인 DDL의 일반 규칙을 따릅니다.
테이블 데이터를 복사해야하는지 테이블을 "내부"에서 재구성 할 수 있는지, 또는이 둘의 조합 하는가?
테이블에 자동 증가 컬럼이 포함되어 있는지 여부.
기반이되는 데이터베이스 작업의 성질 또는 ALTER TABLE 문에서 지정한 LOCK 절은 어떤 수준의 잠금 을 필요로 하는가?

이 섹션에서는 이러한 요인이 InnoDB 테이블에서 다양한 종류의 ALTER TABLE 조작에 어떤 영향을 미치는지에 대해 설명합니다.

온라인 DDL 오류 상태

온라인 DDL 작업이 실패 할 가능성이있는 주요 이유는 다음과 같습니다.

LOCK 절이 특정 유형의 DDL 작업과 호환되지 않는 낮은 수준의 잠금 ( SHARED 또는 NONE )를 지정하는 경우.
DDL 작업의 초기 및 최종 단계에서 짧은 시간 동안 필요한 테이블에 대한 배타적 락 의 취득을 대기하고있는 동안 시간이 초과 한 경우.
인덱스 작성 중에 MySQL이 디스크에 임시 정렬 파일을 쓰는 동안 tmpdir 파일 시스템의 디스크 공간이 부족한 경우.
ALTER TABLE 오랜 시간이 너무 걸리거나 병렬 DML에 의한 테이블 변경이 너무 많거나하여 일시적인 온라인 로그의 크기가 innodb_online_alter_log_max_size 구성 옵션 값을 초과하는 경우. 이 상태는 DB_ONLINE_LOG_TOO_BIG 오류의 원인이됩니다.
병렬 DML이 원래 테이블 정의에서 허용되지만, 새로운 테이블 정의에서 허용되지 않는 테이블을 변경 한 경우. 이 작업은 MySQL이 가장 마지막에 병렬 DML 문에서의 모든 변경 사항을 적용하려고 한 경우에만 실패합니다. 예를 들어, 고유 인덱스를 작성하는 동안 컬럼에 중복 된 값을 삽입하거나 그 열에서 기본 키 인덱스를 작성하는 동안 컬럼에 NULL 값을 삽입 할 수 있습니다. 병렬 DML에 의해 변경된 내용이 우선되고 ALTER TABLE 작업은 실질적으로 롤백 됩니다.

구성 옵션 innodb_file_per_table 은 InnoDB 테이블의 표현에 큰 영향을 미치지 만 그 옵션이 활성화 또는 비활성화되어 모기장 테이블이 물리적으로 독자적인 .ibd 파일 내에서 또는 시스템 테이블 스페이스 내부의 어느 배치되어 있는지에 관계없이 모든 온라인 DDL 작업이 아니라 제대로 작동합니다.

InnoDB는 테이블의 모든 데이터를 나타내는 클러스터 된 인덱스 와 쿼리를 고속화하기위한 옵션의 보조 인덱스 는 두 가지 유형의 인덱스가 있습니다. 클러스터 된 인덱스는 B 트리 노드의 데이터 값이 포함되어 있기 때문에 클러스터 된 인덱스의 추가 또는 삭제는 데이터의 복사 및 테이블의 새로운 카피의 작성이 포함됩니다. 그러나 보조 인덱스는 인덱스 키와 기본 키 값 만 포함됩니다. 이 유형의 인덱스는 클러스터 된 인덱스의 데이터를 복사하지 않고도 만들거나 삭제할 수 있습니다. 각 보조 인덱스는 기본 키 값의 사본 (필요에 따라 클러스터 된 인덱스에 액세스하는 데 사용됩니다)이 포함되어 있기 때문에 기본 키 정의를 변경하면 모든 보조 인덱스도 다시 작성됩니다.

보조 인덱스의 삭제는 간단합니다. 내부 InnoDB 시스템 테이블과 MySQL 데이터 사전 테이블이 인덱스는 존재하지 않게되었다는 사실을 반영하도록 업데이트 될뿐입니다. InnoDB는이 인덱스에 사용되는 스토리지를 그것이 포함 된 테이블 공간에 반환하고 새로운 인덱스 또는 추가 테이블 행이이 공간을 사용할 수 있도록합니다.

기존 테이블에 보조 인덱스를 추가하려면 InnoDB는 테이블을 스캔하여 메모리 버퍼와 임시 파일을 사용하여 각 행을 보조 인덱스 키 컬럼의 값에 순서대로 정렬합니다. 다음은 B 트리 키 값의 순서로 구성됩니다. 이것은 행을 인덱스에 무작위 순서로 삽입하는 것보다 효율적입니다. B 트리 노드가 가득 차면 분할되기 때문에 이렇게하여 인덱스를 구축하면 인덱스의 필 팩터가 높아 후속 액세스가 더 효율적입니다.

기본 키와 하위 키의 인덱스

이전부터 MySQL 서버와 InnoDB 는 각각 테이블 및 인덱스 구조에 관한 자신의 메타 데이터를 보유하고 있습니다. MySQL 서버가 이러한 정보를 트랜잭션 메커니즘에 의해 보호되지 않는 .frm 파일 에 저장하는 반면 InnoDB 는 자신의 데이터 사전 을 시스템 테이블 공간 의 일부로 보유하고 있습니다. DDL 작업이 도중에 중단 또는 기타 예기치 않은 이벤트에 의해 중단 된 경우 메타 데이터가 이러한 두 위치 사이에 일관성이없는 상태로 남아 부팅 오류 또는 변경 도중이었다 테이블에 액세스 할 수없는 등의 문제가 발생할 수 있습니다. InnoDB 는 현재 기본 스토리지 엔진이기 때문에 이러한 문제에 대처은 높은 우선 순위를 가지고 있습니다. 이러한 DDL 작업에 대한 확장을 통해 이러한 문제가 발생할 수있는 기간이 줄어 듭니다.