[친절한 SQL 튜닝] SQL 캐시

개요

앞서 내부 프로시저는 SQL파싱 -> 최적화 -> 로우소스 생성 의 과정을 거쳐 생성된다고 했다.
매번 SQL을 실행할 때마다 위와같은 동작을 하게되면 당연히 퍼포먼스적 측면에서 좋은점수를 받지 못한다.
때문에 내부 프로시저를 라이브러리 캐시에 캐싱해서 성능을 끌어올린다.

소프트파싱과 하드파싱의 구분

1. 사용자가 SQL 문을 전달하면, DBMS는 SQL을 파싱한 후 해당 SQL이 라이브러리 캐시에 존재하는 지 확인한다.
   1-1. 해당 SQL이 라이브러리캐시에 있다면 캐시에서 찾아 곧바로 실행단계로 넘어가는 것을 소프트파싱이라한다.
   1-2. 해당 SQL이 라이브러리캐시에 없다면 최적화 및 로우 소스 생성까지의 단계를 모두 거치는 것을 하드파싱이라 한다.

캐시는 어떤 기준으로 하는가?

• SQL은 이름이 없다. 전체 텍스트가 이름역할을 하기 때문에 조금만 달라도 서로 다른 SQL이라 인식해서 하드파싱을 한다. 예를 들어 다음 SQL문은 서로 다른 SQL로 인식한다.

  SELECT * FROM emp WHERE empno = 7900;
  select * from emp where empno = 7900;

  아래와 같은 자바코드도 사용자마다 loginId가 다를 것이니 매번 하드파싱을 할 것이다.

  public void login(String loginId) {
    String sql = "SELECT * FROM CUSTOMER WHERE LOGIN_ID = '" + loginId + "'";
    // sql호출하는 코드
  }

• 이를 타개하기 위해서 바인드변수를 사용하면 된다.

  public void login(String loginId) {
    String sql = "SELECT * FROM CUSTOMER WHERE LOGIN_ID = ?";
    PreparedStatement st = connection.prepareStatement(sql);
    st.setString(1, loginId);
    //...
  }

  이 SQL에 대한 하드파싱은 최초 한번만 일어나고, 캐싱된 SQL을 사용자들이 공유하며 재사용한다.