8.5.2 InnoDB 트랜잭션 관리 최적화
InnoDB
트랜잭션 처리를 최적화하려면 트랜잭션 기능의 성능 오버 헤드와 서버의 워크로드의 이상적인 균형을 찾습니다. 예를 들어, 응용 프로그램에서 초당 수천 번 커밋 할 때 성능 문제가 발생하고 몇 시간에 한 번 커밋 할 때 다른 성능 문제가 발생할 수 있습니다.
기본 MySQL 설정
AUTOCOMMIT=1
은 바쁜 데이터베이스 서버에 성능 제한을 부과 할 수 있습니다. 현실이라면SET AUTOCOMMIT=0
또는START TRANSACTION
문을 실행하고 모든 변경을 행한 뒤에,COMMIT
문을 발행하여 여러 관련 DML 작업을 단일 트랜잭션에 정리합니다.InnoDB
는 트랜잭션이 데이터베이스가 변경된 경우 트랜잭션의 커밋마다 로그를 디스크에 플래시해야합니다. 변경 될 때마다 나중에 확약하는 경우 (기본 자동 커밋 설정처럼) 저장 장치의 I / O 처리량에 따라 초당 수있는 작업 수가 제한됩니다.또는 단일
SELECT
문으로 만 구성되어 트랜잭션의 경우,AUTOCOMMIT
을 선택하면InnoDB
가 읽기 전용 트랜잭션을 인식하고이를 최적화하는 데 도움이됩니다. 요구 사항은 섹션 14.13.14 "InnoDB의 읽기 전용 트랜잭션 최적화" 를 참조하십시오.대량의 행을 삽입, 업데이트 또는 삭제 후 롤백을 실행하지 마십시오. 큰 트랜잭션에 의해 서버의 성능이 저하 될 경우 그것을 롤백하면 문제가 악화 원래 DML 작업의 몇 배의 실행 시간이 걸릴 수 있습니다. 롤백은 서버를 시작할 때 다시 시작되므로 데이터베이스 프로세스를 강제 종료해도 도움이되지 않습니다.
이 문제의 발생 가능성을 최소화하려면 : 모든 DML 변경을 즉시 디스크에 기록하지 않고 캐시 할 수 있도록 버퍼 풀 의 크기를 늘립니다. 삽입뿐만 아니라, 업데이트 및 삭제 작업이 버퍼링되도록
innodb_change_buffering=all
을 설정합니다. 큰 DML 작업 중에COMMIT
문을 정기적으로 발행하고 가능하면 하나의 삭제 또는 갱신을 약간 줄에서 작업하는 여러 개의 문으로 분할하는 것을 고려합니다.롤백 폭주가 발생한 경우에 그것을 해소하려면 롤백이 CPU에 의존하고 빠르게 실행하도록 버퍼 풀을 증가하거나 섹션 14.16.1 "InnoDB 복구 프로세스" 에 설명 하도록 서버를 강제 종료하고
innodb_force_recovery=3
으로 다시 시작합니다.이 문제는 MySQL 5.5 이상 또는 InnoDB 플러그인이있는 MySQL 5.1에서는 그다지 눈에 띄지 않게 것으로 예상됩니다. 기본 설정
innodb_change_buffering=all
통해 업데이트 및 삭제 작업이 메모리에 캐시 된 그것들이 결코 빠르게 실행되게 필요한 경우에 롤백도 빨라진 것입니다. 많은 삽입, 업데이트 또는 삭제를 수반하는 장기 실행 트랜잭션을 처리하는 서버에서이 매개 변수 설정을 사용하도록하십시오.충돌이 발생한 경우 최신 커밋 된 트랜잭션의 일부 손실을 허용 할 경우는
innodb_flush_log_at_trx_commit
파라미터를 0으로 설정할 수 있습니다. 플래시가 보장되어 있지 않더라도InnoDB
는 어쨌든 1 초에 1 회 로그를 플래시하려고합니다. 또한innodb_support_xa
값을 0으로 설정하고이를 통해 디스크에 데이터와 바이너리 로그의 동기화에 의한 디스크 플래시의 수를 줄일 수 있습니다.행이 변경되거나 삭제되는 경우 행과 관련된 Undo 로그 는 즉시 또는 트랜잭션의 커밋 직후에도 물리적으로 제거되지 않습니다. 이전 또는 동시에 시작한 트랜잭션이 끝날 때까지 이전 데이터는 유지되기 때문에 그 트랜잭션은 변경 또는 삭제 된 행의 이전 상태에 액세스 할 수 있습니다. 따라서 장기 실행 트랜잭션은
InnoDB
가 다른 트랜잭션에 의해 변경된 데이터를 제거하는 것을 방해 할 수 있습니다.장기 실행 트랜잭션에서 행이 변경되거나 삭제 된 경우,
READ COMMITTED
및REPEATABLE READ
격리 수준을 사용하는 다른 트랜잭션은 오래된 데이터를 재구성하기 위해 그 같은 행을 읽을 경우 많은 작업을 수행해야합니다.장기 실행 트랜잭션 테이블이 수정 된 경우 다른 트랜잭션에서 테이블에 대한 쿼리는 첨부 인덱스 기법을 이용하지 않습니다. 일반적으로 보조 인덱스에서 모든 결과 컬럼을 취득 할 수있는 쿼리 대신 테이블 데이터에서 해당 값을 조회합니다.
보조 인덱스 페이지에 새 너무
PAGE_MAX_TRX_ID
가있는 것으로 감지 된 경우 또는 보조 인덱스에서 레코드 삭제가 표시되어있는 경우,InnoDB
는 클러스터 된 인덱스를 사용하여 레코드를 조회해야 가있을 수 있습니다.