공통 전제

같은 조회 요청이어도 DB가 보는 SQL 텍스트는 다를 수 있습니다

바뀌는 것은 id 값뿐입니다. 그런데 애플리케이션이 값을 SQL 문자열에 직접 넣으면, DB는 매번 다른 문장으로 보고 새로 파싱합니다.

id = 1

id = 2

id = 3

같은 업무

users 한 건 조회

리터럴 직접 삽입

값이 바뀔 때마다 SQL도 새 문장

캐시는 SQL 문자열 기준으로 동작하므로, 같은 조회라도 재사용 지점이 잘 생기지 않습니다.

생성된 SQL

SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
SELECT * FROM users WHERE id = 3;

캐시 인식

SQL#1 → plan A SQL#2 → plan B SQL#3 → plan C

값이 달라질 때마다 서로 다른 캐시 엔트리로 인식됩니다.

운영 결과

Hard Parse 반복으로 CPU 사용량과 파싱 경합이 커집니다. 동시 요청이 늘수록 병목이 되기 쉽습니다.

바인드 변수 사용

SQL 템플릿이 유지되므로 처음 만든 실행 계획을 계속 재사용할 수 있습니다.

생성된 SQL

SELECT * FROM users WHERE id = :id;

id = 1 / 2 / 3

캐시 인식

SQL 1개 → plan A 재사용

입력값은 달라도 같은 SQL 형태로 보이기 때문에 하나의 캐시 엔트리로 모입니다.

운영 결과

처음만 Hard Parse, 이후는 Soft Parse로 넘어가 응답이 더 안정적이고 처리량도 유리합니다.

학습 포인트

바인드 변수의 핵심은 값을 숨기는 것이 아니라, SQL 형태를 고정해 캐시 재사용을 가능하게 만드는 것입니다.

함께 얻는 효과

같은 습관이 SQL Injection 방지에도 직접 연결됩니다. 성능과 안전성을 동시에 챙기는 기본기입니다.