저장 프로시저를 호출하는 것은 삽입을 호출하는 것보다 훨씬 느리고 일괄 삽입은 기본적으로 동일합니다. 이유는 무엇입니까?
P粉877719694
P粉877719694 2024-03-30 12:42:40
0
1
434

아래와 같은 테이블과 저장 프로시저가 있습니다.

으아악

저는 단순히 삽입을 호출하는 것보다 저장 프로시저를 호출하는 것이 훨씬 빠르다고 가정했습니다. 하지만 놀랍게도 그렇지 않습니다. 10000개의 레코드 행을 삽입하면 삽입 명령에 약 4분이 걸리고 저장 프로시저에 약 15분이 걸립니다.

이를 확인하기 위해 여러 번 테스트를 실행했습니다. MySQL 서버는 고급 서버는 아니지만 저장 프로시저 호출이 왜 그렇게 느린지 이해할 수 없습니다.

으아악

그런데 삽입 속도를 높이기 위해 innodb_flush_log_at_trx_commit = 2를 설정할 수 있다는 기사를 읽었지만 그렇게 하지 않을 것입니다.

--- 업데이트 ---

얻은 답변을 토대로 일괄 삽입(executemany)을 시도하여 개선 사항이 있는지 확인했지만 놀랍게도 개선 사항이 없었습니다 .

으아악

여러 번 시도해 보았는데(또한 executemany 1샷에 100개의 레코드를 시도함) 성능이 기본적으로 동일하다는 것을 알았습니다.

이게 왜요?

--- 업데이트 2 ---

삽입이 왜 이렇게 느린지 드디어 이해가 되네요! 내 노트북에서 스크립트를 실행하고 외부 호스트 이름에서 데이터베이스에 액세스하고 있기 때문입니다. 스크립트를 서버에 업로드하고 인트라넷 내에서 데이터베이스에 액세스한 후에는 속도가 훨씬 빨라졌습니다. 10,000개의 레코드를 삽입하는 데는 약 3~4초가 걸리며, 100,000개의 레코드를 삽입하는 데는 약 36초가 걸립니다. 인터넷이 부족하면 그런 변화가 생길 것입니다!

하지만 executemany제 경우에는 성능이 향상되지 않았습니다.

P粉877719694
P粉877719694

모든 응답(1)
P粉080643975

귀하의 예에서는 저장 프로시저의 장점을 전혀 활용하지 않기 때문에 저장 프로시저를 인정하지 않습니다.

저장 프로시저의 주요 장점은 다음과 같습니다.

  • 컴파일됨
  • 네트워크 교환이 절약됩니다 (계산이 서버측에서 이루어지므로)

UPDATE를 통해 조작할 수 없을 만큼 복잡한 논리가 있고 이를 수행하려고 한다고 가정합니다. 예를 들어 Python에서는 다음이 필요합니다.

  • 행 선택 -> 네트워크 트래픽 [서버 -> 클라이언트]
  • 행 업데이트 중 -> 매우 느림: Python이 해석됩니다. SQLAlchemy와 같은 ORM을 사용하면(개체는 메모리에 생성되어야 함) 더 느려질 수 있습니다
  • 업데이트된 행 다시 보내기 -> 네트워크 트래픽 [클라이언트 -> 서버]

저장 프로시저를 사용하여 구현된 동일한 예를 상상해 보세요. 이런 종류의 예에서는 저장 프로시저가 실제로 변화를 가져올 가능성이 높습니다.

귀하의 예에는 논리가 없고 행만 삽입하기만 하면 됩니다. 이는 I/O 바인딩 사용 사례입니다. 컴파일된 프로그램을 사용하면 이점이 거의 또는 전혀 없습니다. INSERT를 사용할 때와 마찬가지로 많은 네트워크 교환이 가능합니다. 어느 쪽이든 행을 서버로 보내야 합니다. 네트워크 트래픽도 증가하지 않았습니다.

귀하의 예에서는 아마도 批量插入가 최고의 성과를 달성하는 데 도움이 될 수 있습니다.

최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿