아래와 같은 테이블과 저장 프로시저가 있습니다.
으아악저는 단순히 삽입을 호출하는 것보다 저장 프로시저를 호출하는 것이 훨씬 빠르다고 가정했습니다. 하지만 놀랍게도 그렇지 않습니다. 10000개의 레코드 행을 삽입하면 삽입 명령에 약 4분이 걸리고 저장 프로시저에 약 15분이 걸립니다.
이를 확인하기 위해 여러 번 테스트를 실행했습니다. MySQL 서버는 고급 서버는 아니지만 저장 프로시저 호출이 왜 그렇게 느린지 이해할 수 없습니다.
으아악그런데 삽입 속도를 높이기 위해 innodb_flush_log_at_trx_commit = 2
를 설정할 수 있다는 기사를 읽었지만 그렇게 하지 않을 것입니다.
--- 업데이트 ---
얻은 답변을 토대로 일괄 삽입(executemany
)을 시도하여 개선 사항이 있는지 확인했지만 놀랍게도 개선 사항이 없었습니다 .
여러 번 시도해 보았는데(또한 executemany
1샷에 100개의 레코드를 시도함) 성능이 기본적으로 동일하다는 것을 알았습니다.
이게 왜요?
--- 업데이트 2 ---
삽입이 왜 이렇게 느린지 드디어 이해가 되네요! 내 노트북에서 스크립트를 실행하고 외부 호스트 이름에서 데이터베이스에 액세스하고 있기 때문입니다. 스크립트를 서버에 업로드하고 인트라넷 내에서 데이터베이스에 액세스한 후에는 속도가 훨씬 빨라졌습니다. 10,000개의 레코드를 삽입하는 데는 약 3~4초가 걸리며, 100,000개의 레코드를 삽입하는 데는 약 36초가 걸립니다. 인터넷이 부족하면 그런 변화가 생길 것입니다!
하지만 executemany
제 경우에는 성능이 향상되지 않았습니다.
귀하의 예에서는 저장 프로시저의 장점을 전혀 활용하지 않기 때문에 저장 프로시저를 인정하지 않습니다.
저장 프로시저의 주요 장점은 다음과 같습니다.
UPDATE를 통해 조작할 수 없을 만큼 복잡한 논리가 있고 이를 수행하려고 한다고 가정합니다. 예를 들어 Python에서는 다음이 필요합니다.
저장 프로시저를 사용하여 구현된 동일한 예를 상상해 보세요. 이런 종류의 예에서는 저장 프로시저가 실제로 변화를 가져올 가능성이 높습니다.
귀하의 예에는 논리가 없고 행만 삽입하기만 하면 됩니다. 이는 I/O 바인딩 사용 사례입니다. 컴파일된 프로그램을 사용하면 이점이 거의 또는 전혀 없습니다. INSERT를 사용할 때와 마찬가지로 많은 네트워크 교환이 가능합니다. 어느 쪽이든 행을 서버로 보내야 합니다. 네트워크 트래픽도 증가하지 않았습니다.
귀하의 예에서는 아마도
批量插入
가 최고의 성과를 달성하는 데 도움이 될 수 있습니다.