문제

여러 값 (예 : 1 ~ 100)을 통해 루프 내부에서 준비된 명령문을 실행하고 있습니다.

루프 내부의 직접 실행과 비교하여 트랜잭션을 사용하는 데있어서 이점이 있습니까?

값은 서로에 의존하지 않으므로 해당 관점에서 트랜잭션이 필요하지 않습니다.

도움이 되었습니까?

해결책

쿼리가 인서트 인 경우 페이지입니다 7.2.19. 삽입 문의 속도 MySQL 매뉴얼 중 Transactional Engine을 사용하고 있는지 여부에 따라 두 가지 흥미로운 정보를 제공합니다.

비 트랜잭션 엔진을 사용할 때 :

비 트랜잭션 테이블에 대한 여러 문으로 수행되는 삽입 작업 속도를 높이려면 테이블을 잠그십시오.

인덱스 버퍼가 한 번만 디스크로 플러시되므로 모든 삽입 문이 완료된 후에는 성능에 도움이됩니다. 일반적으로 삽입 문이있는만큼 인덱스 버퍼 플러시가 많이 있습니다. 단일 삽입물로 모든 행을 삽입 할 수있는 경우 명시 적 잠금 문이 필요하지 않습니다.

그리고 트랜잭션 엔진으로 :

트랜잭션 테이블에 대한 빠른 삽입을 얻으려면 잠금 테이블 대신 시작 트랜잭션 및 커밋을 사용해야합니다.

따라서 트랜잭션을 사용하는 것이 좋은 생각 일 수 있지만 서버의로드에 따라 달라질 수 있으며 동시에 동일한 테이블을 사용하여 여러 용도가 있는지 여부와 그 모든 것입니다.

내가 링크 한 페이지에 더 많은 정보가 있으므로 주저하지 말고 읽어보십시오 ;-)


그리고 당신이하고 있다면 업데이트 문 :

빠른 업데이트를 얻는 또 다른 방법은 업데이트를 지연시킨 다음 나중에 연속으로 많은 업데이트를하는 것입니다. 여러 업데이트를 함께 수행하는 것이 테이블을 잠그면 한 번에 하나씩 수행하는 것보다 훨씬 빠릅니다.

따라서 삽입물과 마찬가지로 말할 수 있다고 생각합니다.


BTW : 확실히, 당신은 두 솔루션을 모두 시도하여 벤치마킹 할 수 있습니다. microtime, 예를 들어 PHP 측에서 ;-)

다른 팁

더 빨리 시간 동안 하나의 인서트가 전체 배치가 실패하는 것처럼 한 번에 한 번에 5 또는 10 씩 함께 그룹화 할 수 있습니다.

http://www.desilva.biz/mysql/insert.html

거래하면 속도가 느려질 것이므로 필요하지 않으면 사용하지 마십시오.

매번 쿼리를 계속 구축 할 필요가 없기 때문에 배치 인서트를 사용하더라도 준비된 진술은 좋은 선택입니다.

CSV 파일 (아마도 매우 긴) 데이터 가져 오기를 구현해야 할 때도 같은 질문에 직면했습니다 (나는 당신이 사용할 수 있다는 것을 알고 있습니다. 로드 데이터 그것에 대한 구문이지만 삽입하기 전에 필드에 약간의 처리를 적용해야했습니다).

그래서 나는 거래와 약 15K 행의 파일을 실험했습니다. 결과적으로 하나의 고유 트랜잭션 내에 모든 레코드를 삽입하면 몇 초 밖에 걸리지 않으며 CPU 바운드입니다. 거래를 전혀 사용하지 않으면 몇 분이 걸리고 IO 경계가 있습니다. 모든 N 행을 커밋함으로써 중간 결과를 얻었습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top