Static SQL
String 형 변수에 담지 않고 코드 사이에 직접 기술한 SQL.
Pro*C 과 같은 언어로 코드 사이에 SQL문을 작성하면 PreCompile 시에 해당 SQL문이 파싱 되고 권한이 확인되어 String형 변수에 담긴다.
결국 String형 변수에 담기긴 하지만, Static SQL의 경우 SQL문이 실행 전에 Precompile 되기 때문에 SQL문이 바뀔 일이 없기 때문에 반복해서 실행해도 Syntax, Semantics 체크와 권한, 오류 검사를 또 하지 않는다.
Dynamic SQL
반면 Dynamic SQL은 String 형 변수에 담긴다.
프로그램이 진행함에 따라 쿼리문이 달라지기 때문에
PreCompile 시에 Syntax, Semantics 체크가 불가능하다.
Static or Dynamic?
두 방식의 특징을 고려했을 때, 프로그램 개발 시 Static SQL이 성능에 유리하다.
단, 아래의 경우엔 Dynamic SQL을 쓸 수 있다.
- PreCompile 과정에서 에러가 나는 구문을 사용할 때
- 상황에 변수가 너무 많아서 그에 맞는 Static SQL문을 일일히 다 적을 수가 없고 유지보수도 어려울 때
Dynamic SQL을 쓰더라도 바인드 변수는 꼭 써야 하지만,
다음 경우엔 지양해도 된다.
1. 배치 프로그램, DW, OLAP 등 Long Running 쿼리. 이들은 파싱 소요시간이 총 소요시간에서 차지하는 비중이 매우 낮고 사용빈도도 낮다.
2. OLTP성 애플리케이션이어도 사용빈도가 매우 낮을 경우.
3. 조건절 칼럼의 값의 종류 분포가 들쭉날쭉일 때.
이러면 옵티마이저가 칼럼 히스토그램을 이용하는 게 좋은데, 안 그러면 인덱스 활용이 어렵기 때문이다.
위 1, 2번 경우는 라이브러리 캐시 부하를 유발할 가능성이 없기 때문에, 바인드 변수를 안 써도 된다.
그래도 쓸 수 있으면 쓰는 것이 좋다.
데이터베이스에선...
두 쿼리는 애플리케이션 개발할 때 구분된다.
데이터베이스 입장에선 둘은 차이가 없으며, 도착한 SQL문을 똑같이 인식한다.
둘의 성능 차이는 애플리케이션 커서 캐싱 기능에 있다.
이를 사용하지 않으면 둘은 동일한 성능을 낸다.
Dynamic SQL은 애플리케이션 커서를 캐싱할 수 없지만
데이터베이스에서 진행되는 라이브러리 캐싱은 동일하게 진행된다.
따라서 라이브러리 캐시 효율을 논할 때 초점은 바인드 변수 사용 여부에 맞춰져야 한다.
