PrepareStatment(#)와 Statment($)

PrepareStatment(#)와 Statment($)

1. #의 사용 (PrepareStatment)
- #을 사용할 경우 오라클의 PreparedStatment를 사용하게 된다.

  예제(name=John)
   a. mybatis mapper
      SELECT NAME FROM TEST WHERE NAME=#{name}
   b. 오라클에서 받은 쿼리
      SELECT NAME FROM TEST WHERE NAME = ?

실제 수행 쿼리
SELECT NAME FROM TEST WHERE NAME='John'

2. $의 사용(Statment)
- $는 간단히 스트링 자체를 변환(REPLACE)해 버린다

  예제(score=99)
   a. mybatis mapper
      SELECT NAME FROM TEST WHERE SCORE=${score}
   b. 오라클에서 받은 쿼리
      SELECT NAME FROM TEST WHERE SCORE=99


실제 수행 쿼리
SELECT NAME FROM TEST WHERE NAME=99

3. 차이
두 가지가 똑같아 보이지만 붉게 처리된 부분을 볼 경우 1번은 오라클에서 변수를 바인드 처리 하기 때문에
NAME 값이 달라질 경우 같은 쿼리로 인식하게 됩니다.
(반드시는 아니지만 일반적으로 오라클의 쿼리 파싱, 캐시 등의 이점으로 CPU 및 수행 속도 차이가 나게 됩니다)

2번의 경우 b부분을 봤을때 쿼리 자체가 변경되어 들어가기 때문에 SCORE가 다른값이 올 경우
오라클은 이를 완전 다른 쿼리로 인식하기 때문에 새로 파싱 등의 작업을 하게 되고 속도가 느려질 우려가 있습니다.

캐쉬를 확인한후에 동일한 명령이 있으면 캐쉬에서 꺼내어 DB에 접근하고 없으면 실행계획을 세우고 JDBC를 로드하여 DB에 접근.

PreparedStatment를 사용하면 수시로 변화가 되는 인자 값이 히든값으로 그대로 캐쉬로 저장되어, 캐쉬에 들어있는 실행계획의 재사용률이 올라가서 결국은 JDBC로드 또한 줄어듬 statment를 사용하면 인자값을 계속해서  sql에 결합되어 호출하게 될것이고, 매치되는 캐쉬가 줄어들어 JDBC로드를 매번하고 실행계획을 세워야 함으로 cpu 로드 증가

 !여기서 사용하는 캐쉬는 DB의 개념이기에 어플리케이션이 어려개 생성이 되더라도 서로 공유해서 사용이됨, 대형 프로그램일수록 성능차가 크게 발생

---

Procedure(프로시져) 확인하기

많은 Tool을 통해 프로시저 내용을 확인할수 있지만 

손수 확인하고 할땐

 

SELECT    object_name 

FROM      user_objects 

WHERE     object_type = 'PROCEDURE';  --프로시져 찾기

 

SELECT    text 

FROM      user_source 

WHERE     name = 'AA_MAIL';  -- 해당 프로시져 내용 보기