[REFACTOR] HikariCP MySQL 캐싱 설정

[jminkkk]

📌 어떤 기능을 리팩터링 하나요?

학습 테스트에 제시된 MySQL 사용 시 적용하면 좋을 설정을 추가해봐요.

https://github.com/brettwooldridge/HikariCP/wiki/MySQL-Configuration

제시된 설정은 다음과 같습니다.

dataSource.cachePrepStmts=true
dataSource.prepStmtCacheSize=250
dataSource.prepStmtCacheSqlLimit=2048
dataSource.useServerPrepStmts=true
dataSource.useLocalSessionState=true
dataSource.rewriteBatchedStatements=true
dataSource.cacheResultSetMetadata=true
dataSource.cacheServerConfiguration=true
dataSource.elideSetAutoCommits=true
dataSource.maintainTimeStats=false

AS-IS

none

TO-BE

제가 생각하기에 추가하면 좋을 것 같은 설정
batch는 수행하고 있지 않기 때문에 아래의 값들을 추가하면 좋을 것 같습니답~!

dataSource.cachePrepStmts=true
dataSource.prepStmtCacheSize=250
dataSource.prepStmtCacheSqlLimit=2048
dataSource.useServerPrepStmts=true
dataSource.useLocalSessionState=true 
dataSource.cacheResultSetMetadata=true 
dataSource.cacheServerConfiguration=true 
dataSource.elideSetAutoCommits=true 
dataSource.maintainTimeStats=false 

⏳ 예상 소요 시간

이슈를 완료하기까지 예상되는 소요 시간을 분 or 시간 or 일 단위로 작성해주세요.

🔍 참고할만한 자료(선택)

[jminkkk]

각 설정별 의미

• dataSource.cachePrepStmts=true
  • PreparedStatement를 캐시에 저장하여 재사용합니다.
• dataSource.prepStmtCacheSize=250
  • 캐시할 PreparedStatement의 최대 개수를 250개로 설정합니다.
  • 우리 서비스 쿼리가 250개 이하일 것 같긴 한데 확인해보면 좋을 것 같습니다.
• dataSource.prepStmtCacheSqlLimit=2048
  • 캐시할 SQL 문의 최대 길이를 2048자로 제한합니다.
  • 검색 쿼리가 간당간당한 것 같아서 이것도 조사 필요할 듯
• dataSource.useServerPrepStmts=true
  • 서버 측 PreparedStatement를 사용합니다.
• dataSource.useLocalSessionState=true
  • 로컬 세션 상태를 사용하여 불필요한 명령을 줄입니다.
• dataSource.cacheResultSetMetadata=true
  • ResultSet 메타데이터를 캐시하여 성능을 개선합니다.
• dataSource.cacheServerConfiguration=true
  • 서버 구성을 캐시하여 연결 시간을 단축합니다.
• dataSource.elideSetAutoCommits=true
  • 불필요한 autocommit 설정을 생략하여 성능을 향상시킵니다.
• dataSource.maintainTimeStats=false
  • 시간 통계 유지를 비활성화하여 오버헤드를 줄입니다.

[jminkkk]

dataSource.useServerPrepStmts=true

• 서버 측 PreparedStatement를 사용합니다.

이거 무슨 뜻일까? Claude 선생님 왈

dataSource.useServerPrepStmts=true에 대해 더 자세히 설명드리겠습니다.

이 설정은 서버 측 PreparedStatement를 사용하도록 지시합니다. 이해를 돕기 위해 PreparedStatement의 두 가지 주요 유형을 비교해보겠습니다:

1. 클라이언트 측 PreparedStatement:

   • SQL 쿼리가 클라이언트(애플리케이션) 측에서 준비됩니다.
   • 매 실행마다 전체 쿼리가 서버로 전송됩니다.

2. 서버 측 PreparedStatement:

   • SQL 쿼리가 데이터베이스 서버 측에서 준비되고 저장됩니다.
   • 쿼리는 한 번만 서버로 전송되고, 이후에는 매개변수만 전송됩니다.

서버 측 PreparedStatement(useServerPrepStmts=true)를 사용할 때의 장점:

• 쿼리 파싱과 최적화가 서버에서 한 번만 수행됩니다.
• 네트워크 트래픽이 줄어듭니다 (전체 쿼리 대신 매개변수만 전송).
• SQL 인젝션 공격에 대한 보호가 강화됩니다.
• 데이터베이스 서버의 쿼리 캐시를 더 효과적으로 활용합니다.
• 동일한 쿼리에 대해 일관된 실행 계획을 보장합니다.

하지만 모든 상황에서 항상 좋은 것은 아닙니다. 간단한 쿼리나 한 번만 실행되는 쿼리의 경우, 오히려 오버헤드가 발생할 수 있습니다. 따라서 애플리케이션의 특성과 데이터베이스 사용 패턴을 고려하여 이 옵션의 사용 여부를 결정해야 합니다.

+) 서버 측 PreparedStatement 가 JDBC의 PreparedStatement를 의미하는 건 아님.
말 그대로 데이터베이스 서버 측의 쿼리 실행을 위해 준비해야 하는 구문을 말하는 거임