[친절한 SQL 튜닝] 1.2 SQL 공유 및 재사용

1.2.1 소프트 파싱 vs. 하드 파싱

내부 프로시저를 캐싱해두는 공간을 라이브러리 캐시 라고 한다.

서버 프로세스와 백그라운드 프로세스가 공통으로 액세스하는 데이터와 제어 구조를 캐싱하는 공간을 SGA 라고 하는데 라이브러리 캐시는 SGA 의 구성요소이다.

SQL 을 파싱한 후 해당 SQL 이 캐시에 존재하는지 확인하는데,

• 캐시에서 찾으면: 바로 실행단계로 넘어간다, 이를 소프트 파싱 이라고 함
• 캐시에서 못찾으면: 최적화 및 로우 생성 단계까지 모두 거치는 것을 하드 파싱 이라고 한다.

SQL 최적화 과정을 hard 라고 표현하는 이유는 최적화에 많은 단계가 있고, 고려해야 할 부분이 많아서이다.

따라서, 라이브러리 캐시가 존재한다.

1.2.2 바인드 변수의 중요성

SQL 은 이름이 없다

SQL 이름이 없다, SQL 문 자체가 이름이기 때문에, 텍스트중 작은 부분만 수정되어도 그 순간 다른 객체가 생성된다.

DB 에서 수행되는 많은 SQL이 일회성도 많고 수시로 변경되기 때문에, SQL 을 영구 저장하지 않는다.

공유 가능 SQL

따라서 아래는, 실행의미는 전부 같지만, 각각 별도의 라이브러리 캐시 공간을 사용한다.

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

만약, 코드를 아래와 같이 동적으로 받는다면, 실행할때마다 다른 라이브러리 캐시 공간을 이용 할 것이다.

SELECT * FROM CUSTOMER WHERE LOGIN_ID = '"+login_id+"'"

이러한 낭비를 방지하기 위해 파라미터 Driven 방식인 바인드 변수를 사용하면

SELECT * FROM CUSTOMER WHERE LOGIN_ID = ?

위 SQL 을 통해 100만이 사용해도 하드파싱은 최초 한번만 일어나고, 캐싱된 SQL 을 공유해서 재사용 한다.