MySQL 트랜잭션 크기-너무 큰가?

나는 종종 너무 자주 실행되는 가져 오기 프로세스를 가지고 있으며, 트랜잭션이라고하는 '전부 또는 전무'종류의 거래가되기를 원합니다.

여러 측면이 있으며 수입은 100k-1mil + 기록 사이의 어느 곳에서나 산출 될 수 있습니다. 이것은 몇 MB에서 수백 MB의 데이터 범위에 해당하는 페이로드와 같습니다.

임시 테이블이 또 다른 옵션이라는 것을 알고 있지만이 방법은 매우 유용합니다.

커밋 사이에 많은 양의 데이터 조작으로 이러한 종류의 연습에 대해 알아야 할주의 사항이 있습니까? (커밋 된 일반적인 쓰기 / 인덱싱로드 버스트 외부)

알아야 할 한 가지 병목 현상은 InnoDB 로그 버퍼입니다. 크기는 innodb_log_buffer_size에 의해 설정됩니다 . 다음은 MySQL 설명서에 대한 내용입니다.

InnoDB가 디스크의 로그 파일에 쓰는 데 사용하는 버퍼 크기 (바이트)입니다. 기본값은 8MB입니다. 큰 로그 버퍼를 사용하면 트랜잭션을 커밋하기 전에 디스크에 로그를 쓰지 않고도 큰 트랜잭션을 실행할 수 있습니다. 따라서 큰 트랜잭션이있는 경우 로그 버퍼를 크게하면 디스크 I / O가 절약됩니다.

InnoDB 로그 버퍼를 InnoDB 버퍼 풀과 혼동해서는 안됩니다. 그들 사이의 주요 차이점은 그들의 목적입니다. InnoDB 로그 버퍼는 기본적으로 리두 로그 (ib_logfile0, ib_logfile1)에 기록되는 단기 변경 사항을 기록합니다. InnoDB 버퍼 풀 ( innodb_buffer_pool_size로 크기 조정 )은 커밋 (페이지가 더티 인 경우)되고 결국 기록 될 데이터 및 인덱스 페이지를 디스크에 캐시합니다. 일단 커밋되면 변경 페이지는 LRU 규칙을 통해 제거 될 때까지 RAM에 남아 있습니다.

큰 트랜잭션은 로그 버퍼를 통과해야합니다. 언급했듯이 로그 버퍼가 클수록 디스크 I / O가 줄어 듭니다. 커밋이 크면 병목 현상이 발생합니다.

구성 할 다른 InnoDB 옵션을 살펴볼 수 있습니다.

• innodb_flush_method : 이것은 플러시 처리 방법과 OS가 InnoDB에 쓰기를 캐시 할 수 있는지 여부를 나타냅니다 ( O_DSYNC와 O_DIRECT 사이에서 실험해야 함 )
• innodb_read_io_threads (최대 사용 : 64)
• innodb_write_io_threads (최대 사용 : 64)
• innodb_io_capacity (5000 또는 10000과 같은 더 높은 값을 사용하지만 하드웨어가이를 대신합니다. 즉, 큰 수를 할당하면 하드웨어가 IO 용량을 결정하도록합니다)
• innodb_thread_concurrency : 기본값은 0입니다. Percona NYC 2011의 Ronald Bradford로부터이 숫자를 0으로 남겨두기 위해 직접 배웠습니다. InnoDB 가 처리 할 수 있는 최상의 동시성 티켓 수를 결정할 수 있습니다)

추가 연구를 위해 InnoDB 최적화에 대한 다른 게시물이 있습니다.

• InnoDB 기본 설정 최적화
• 무거운 InnoDB 워크로드에 맞게 MySQL을 어떻게 조정합니까?
• 삽입이 많은 InnoDB 테이블은 모든 CPU를 사용하지 않습니다
• InnoDB DELETE 성능을 향상시키는 방법은 무엇입니까?
• MySql-ibdata1 정리