친절한 SQL 튜닝을 읽으면서 느낀점입니다.
하드 파싱을 조심해야 하는 이유
1. 소프트 파싱 vs 하드 파싱
우리가 sql을 질의하면 일어나는 일
- 사용자가 SQL문을 전달하면 DBMS는 SQL을 파싱한 후 해당 SQL이 라이브러리 캐시에 존재하는지 확인
- 만약 캐시에서 찾으면 곧바로 실행
- 캐시에 없다면 최적화 단계를 거침
캐시에서 찾아 곧바로 실행하면 소프트 파싱, 찾는것에 실패해 최적화를 실행해야 하면 하드 파싱이라고 한다.
2. 하드 파싱이 안좋은 이유 및 라이브러리 캐시가 필요한 이유
최적화 하는데 cpu 자원을 많이 사용한다. 예를 들어 5개의 테이블을 조인하는 쿼리문 하나를 최적화 할때 조인순서만 고려해도 120가지이다.(5!=120) 여기에 조인의 옵션(NL조인, 소트 머지 조인, 해시조인 등등) 을 고려한다면 경우의 수는 더욱 늘어난다. 즉 하나의 쿼리를 수행하는 데 있어 최적화 하는데 걸리는 과정은 결코 가벼울수 없다. 데이터 베이스에서 이루어지는 처리 과정은 대부분 i/o작업에 집중되는 반면, 하드 파싱은 cpu를 많이 소비하는 몇 안 되는 작업 중 하나이다. 이런 작업을 거쳐 생성한 내부 프로시저를 한 번만 사용하고 버린다면 매우 비효율 적이다. 라이브러리 캐시가 필요한 이유가 여기에 있다.
3. 아래는 하드 파싱한 코드가 초래하는 일
라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값이 sql 문 그자체 이다. 만약 500만 고객이 동시에 여러번 아래의 코드로 로그인 한다고 생각해보자.
DBMS에 발생하는 부하는 대개 과도한 I/O가 원인인데, 오히려 I/O가 발생하지 않고 CPU 사용률이 올라가는 일이 초래할 것이다. 아마 라이브러리 캐시를 보면 아래와 같은 sql이 가득 있을 것이다.
4. 바인드 변수의 활용
위와 같은 이유들로 하드 파싱을 피하고 바인드 변수를 활용하여 소프트 파싱을 적극 활용하자.
아래코드는 하드파싱은 최초 한번만 일어나고 캐싱된 SQL을 공유할 것 이다.
