한 번에 Statement 한 개만 사용하면 내 Connection과 함께 캐싱하는 것이 좋습니다. 나는 거의 모든 비용을 지불하지 않고 명세서를 캐시 할 수 있도록 이미 연결을 캐시한다.명세서 비용이 얼마입니까
본질적으로 진술을 작성하는 데 비용이나 간접비가 있는지 묻고 싶습니다. 나는 준비된 진술을 만드는 것의 이점을 완전히 이해한다. 나는 구체적으로 Connection.createStatement()에 대해 이야기하고 있습니다.
오픈 소스 jdbc 드라이버 (jtds)에 대한 연구에 따르면 생성 된 각 명령문에 대해 다음과 같은 객체 오버 헤드가 제안됩니다. 아마도 그래서 사소한 캐시 -
Connection : 나는 데이터베이스를 조회 할 새로운 Statement마다 만드는 것이 아니라 하나의 캐시 하나를 들고와 그것을 재사용의 비용을 계산하려합니다.TdsCore - 프로토콜 구현처럼 보이지만 그다지 중요하지 않습니다.ResultSet.ArrayList입니다.ResultSet의 ArrayList입니다.따라서 Statement의 비용 중 가장 높은 비율로 실행 된 쿼리가 남겨 둡니다.
계산서 비용은 다른 요인과 독립적으로 계량화 할 수 없습니다. 예 : 데이터베이스, JDBC 드라이버, SQL 문 등이 포함됩니다.
Statement (또는 PreparedStatement) 작성 및 처음 실행시 오버 헤드가 발생할 수 있습니다. 그러나 전체 응용 프로그램의 성능에 중요한 영향을 미치지 않을 가능성이 있습니다. 그리고 그렇지 않다면, 캐싱 코드를 구현하는 것은 낭비 될뿐입니다.
이것이 가치있는 최적화가 될 것인지 아닌지 추측해서는 안됩니다. 이 수행해야하는 것은입니다. 프로그램을 작동시킨 다음 프로파일 링 한 다음 프로파일 링 데이터를 사용하여 최적화해야 할 사항을 결정하십시오. 동일한 쿼리를 실행하는 데 많은 시간이 소요되는 경우 일 수도 있고 캐싱이 도움이 될 수도 있고 그렇지 않을 수도 있습니다. 그것을 시험해보고 성능에서 측정 가능한 차이가 있는지 확인하십시오.
'Connection's을 캐싱하는 것이 좋습니다. 그러므로 항상 시간을 낭비하지 않고'Connection'을 캐시 할 것입니다. 나는 단지 성명서에 대해 비슷한 지혜가 있기를 바랐다. – OldCurmudgeon
연결 캐싱은 필요할 경우에만 좋은 아이디어입니다. 필요하지 않은 경우 구현을 통해 개발자의 시간을 낭비했습니다. 표준 연결 풀 라이브러리가 있기 때문에 불필요하게 사용하면 많은 시간을 낭비하지 않습니다. 그러나 제 요점은 최적화에 시간을 낭비하지 말아야한다는 것입니다. 최적화 기법을 찾는 것이 필요하다는 증거가없는 경우입니다. 그리고 문장 캐싱에 대한 일반적인 증거가 없기 때문에 그것이 존재하는지 의심 스럽습니다. –
필자는 항상 오버 헤드가 있다고 가정하지만 필자는 필요한 성능 향상을 나타내는 측정 값이없는 한 오버 헤드가 응용 프로그램에 추가 할 가치가 없다고 항상 가정합니다. –
다음과 같이됩니다 : 내 응용 프로그램이 수백만 문장을 생성하면 Yes No No ... – Nik