• MySQL매뉴얼
    • MySQL 5.6 매뉴얼
    • MySQL 5.1 매뉴얼
    • MySQL 5.0 매뉴얼
    • MySQL HA 매뉴얼
  • 기술문서
    • Xtrabackup 구성
    • 메모리 사용량 모니터링
  • 라이선스
  • 온라인문의
  • 회사소개
  • → 목 록 (MySQL5.6 한글메뉴얼) [close]
  • 1. MySQL 5.6 새로운 기능
  • 2. MySQL 설치 및 업그레이드
  • 3. MySQL Tutorial
  • 4. MySQL 프로그램
  • 5. MySQL 서버관리
  • 6. 보안
  • 7. 백업 및 복구
  • 8. 최적화
  • 1. 최적화 개요
    2. SQL문 최적화
    3. 최적화 및 인덱스
    4. 데이터베이스 구조의 최적화
    5. InnoDB 테이블의 최적화
    1. InnoDB 테이블의 스토리지 레이아웃 최적화
    2. InnoDB 트랜잭션 관리 최적화
    3. InnoDB 로깅 최적화
    4. InnoDB 테이블의 대량 데이터로드
    5. InnoDB 쿼리 최적화
    6. InnoDB DDL 작업의 최적화
    7. InnoDB 디스크 I / O 최적화
    8. InnoDB 구성 변수의 최적화
    9. 많은 테이블이있는 시스템에 대한 InnoDB의 최적화
    6. MyISAM 테이블의 최적화
    7. MEMORY 테이블 최적화
    8. 쿼리 실행 계획의 이해
    9. 버퍼링과 캐시
    10. 잠금 작업의 최적화
    11. MySQL 서버의 최적화
    12. 성능 측정
  • 9. Language Structure(언어구조)
  • 10. Character Sets(Globalization)
  • 11. 데이터형(Data Types)
  • 12. 함수와 연산자
  • 13. SQL 문법
  • 14. InnoDB 스토리지 엔진
  • 15. 기타 스토리지 엔진
  • 16. 고가용성 및 확장성
  • 17. 리플리케이션
  • 18. MySQL Cluster
  • 19. 파티셔닝
  • 20. Stored Programs and Views
  • 21. INFORMATION_SCHEMA
  • 22. PERFORMANCE SCHEMA
  • 23. 컨넥터 및 API
  • 24. MySQL 확장
  • 25. MySQL Enterprise Edition
  • 26. MySQL Workbench
  • 27. 제약 및 제한
  • 28. MySQL 5.7 새로운 기능

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 는 클러스터 된 인덱스를 사용하여 레코드를 조회해야 가있을 수 있습니다.


서울시 강남구 영동대로 602 6층
TEL: 02-6061-0006  /  E: csr@mysqlkorea.com
주식회사 이노클러스터  등록번호 : 727-86-02261
Copyright © innocluster Co. ltd. all rights reserved