http://www.mysqlkorea.co.kr
한글매뉴얼 5.0 , 한글매뉴얼 5.1 , MySQL 5.1 HA , 사용자매뉴얼
Advanced Knowle...  
엔지니어 노트  
블로그존  
글로벌 MySQL  
MySQL 5.5 GA  
MySQL 5.6 Developer  
최신글
mysql master - s…
김선영 아나운서…
'연애의 맛' 시즌…
[대림 NEWS] 대림…
연애의맛 정준 소…
 
한글매뉴얼 5.0 > 매뉴얼존 > 한글매뉴얼 5.0
 

14.2.6.2. MyISAM 테이블을 InnoDB로 변환하기

 

Important: mysql 데이터 베이스에 있는 MySQL 시스템 테이블 (user 또는 host)InnoDB 타입으로 변환하지 말도록 한다. 이런 연산은 지원되지 않는다. 이러한 시스템 테이블은 항상 MyISAM 타입으로 존재해야 한다.

 

만일 여러분이 모든 테이블 (시스템 테이블이 아닌 것들)InnoDB 테이블 형태로 생성하고자 한다면, 서버 옵션 파일의 [mysqld] 섹션에 default-storage-engine=innodb를 추가하기만 하면 된다.

 

InnoDBMyISAM 스토리지 엔진이 실행하는 것과 같은 방식의 별도 인덱스 생성을 위한 특별한 최적화 기능을 가지고 있지 않다. 따라서, 이 엔진은 테이블을 입력 및 출력하고 인덱스를 나중에 생성하지 않는다.

 

테이블을 InnoDB로 변경하는 가장 빠른 방법은 InnoDB 테이블에 직접 삽입을 하는 것이다. , ALTER TABLE ... ENGINE=INNODB를 사용하거나, 또는 동일한 정의문을 사용해서 빈 InnoDB 테이블을 생성하고 INSERT INTO ... SELECT * FROM ...를 사용해서 열을 삽입하는 것이다.

 

만일 여러분이 UNIQUE 제한 값 (constraint)을 세컨더리 키(secondary key)에 가지고 있다면, 입력 연산 (import)을 하는 동안 임시로 유일성 검사 (uniqueness checks)를 오프함으로써 테이블 입력 (import)의 속도를 향상 시킬 수가 있다:

 

SET UNIQUE_CHECKS=0;

... import operation ...

SET UNIQUE_CHECKS=1; 

 

대형 테이블의 경우에는, 이렇게 하는 것이 디스크 I/O를 많이 절감 시켜 주는데, 그 이유는 InnoDB 가 배치 작업처럼 세컨더리 인덱스 레코드를 기록하기 위해 자신의 삽입 버퍼를 사용할 수 있기 때문이다. 데이터에는 이중 키가 포함되어 있지 않도록 한다. 하지만, UNIQUE_CHECKS는 스토리지 엔진이 이중 키를 무시하도록 요구하지는 않는다.

 

삽입 프로세스를 보다 효과적으로 제어하기 위해서는, 대형 테이블을 부분적으로 삽입하는 것이 좋다:

 

INSERT INTO newtable SELECT * FROM oldtable

   WHERE yourkey > something AND yourkey <= somethingelse; 

 

모든 레코드가 삽입되고 나면, 여러분은 테이블의 이름을 수정할 수 있게 된다.

 

대형 테이블 변환을 하는 동안에는, 디스크 I/O를 떨어뜨리기 위해서 InnoDB 버퍼 풀의 크기를 크게 해야 한다. 하지만, 물리적인 메모리의 80% 이상을 사용하지는 말도록 한다. 또한, InnoDB 로그 파일의 크기도 크게 만든다.

 

테이블스페이스가 가득 차지 않도록 한다: InnoDB 테이블은 MyISAM 테이블 보다 많은 디스크 공간을 필요로 한다. 만일 ALTER TABLE 연산이 공간을 다 차지하게 되면, 롤백이 시작되고, 디스크 바운드 (disk-bound)가 되는 경우에는 여러 시간이 걸리게 된다. 삽입 연산의 경우, InnoDB는 세컨더리 인덱스 레코드를 배치 파일에 있는 인덱스에 병합하기 위해 삽입 버퍼를 사용한다. 이런 동작은 디스크 I/O를 많이 절감시켜준다. 롤백의 경우, 이러한 매커니즘은 사용되지 않으며, 롤백은 삽입에 비해서 30 배 이상 소요가 된다.

 

롤백이 오래 걸리는 (runaway) 경우에는, 데이터베이스에 중요한 값을 가지고 있지 않다면, 디스크 I/O 연산이 종료되기를 기다리는 것보다는 데이터베이스 프로세스를 강제로 종료 (kill)하는 편이 낫다. 강제로 종료 시키는 프로시저에 대해서는 Section 14.2.8.1, “강제로 InnoDB 복구하기를 참조하기 바란다.

 

상위
14.2.6. InnoDB 테이블 생성 …
14.2.6.1. 서로 다른 API를 가…
14.2.6.2. MyISAM 테이블을 Inn…
14.2.6.3. AUTO_INCREMENT 컬럼…
14.2.6.4. FOREIGN 키 제한
14.2.6.5. InnoDB 와 MySQL 리…
MySQL Korea 사이트의 컨텐츠 소유권은 (주)상상이비즈에 있으므로 무단전재를 금합니다.
ⓒ 2010-2011 ssebiz All Rights Reserved.