상황: 매장 코드가 정확히 S033인 주문만 검색한다. 개발자가 습관적으로 LIKE 'S033%'처럼 와일드카드(%)를 붙이면 검색 의미가 달라지고, 일반 B-tree 인덱스를 효율적으로 사용하지 못할 수 있다. 실제 startdbpg.tr_ord의 shop_id에는 tr_ord_fk02 인덱스가 있다.
BAD SQL — 정확한 일치가 필요한데 LIKE 접두사 검색 사용
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF)
SELECT o.ord_no, o.shop_id
FROM startdbpg.tr_ord o
WHERE o.shop_id LIKE 'S033%';
SQL
복사
실측 실행계획 (BAD)
Gather (actual time=0.571..411.922 rows=4182 loops=1)
Workers Planned: 1
Workers Launched: 1
Buffers: shared hit=16174 read=1142
-> Parallel Seq Scan on tr_ord o (actual time=0.029..390.108 rows=2091 loops=2)
Filter: ((shop_id)::text ~~ 'S033%'::text)
Rows Removed by Filter: 363072
Buffers: shared hit=16174 read=1142
Planning:
Buffers: shared hit=119
Planning Time: 0.623 ms
Execution Time: 412.502 ms
Plain Text
복사
GOOD SQL — 정확한 매장 코드는 = 로 비교
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF)
SELECT o.ord_no, o.shop_id
FROM startdbpg.tr_ord o
WHERE o.shop_id = 'S033';
SQL
복사
실측 실행계획 (GOOD)
Index Scan using tr_ord_fk02 on tr_ord o (actual time=0.080..14.185 rows=4182 loops=1)
Index Cond: ((shop_id)::text = 'S033'::text)
Buffers: shared hit=3177
Planning:
Buffers: shared hit=125
Planning Time: 0.624 ms
Execution Time: 14.578 ms
Plain Text
복사
실측 비교: 두 SQL 모두 4,182건을 조회했지만 접근 경로가 달랐다. BAD는 Parallel Seq Scan + Filter로 테이블을 광범위하게 읽었고, GOOD은 tr_ord_fk02의 Index Cond를 사용했다. 버퍼 사용량은 BAD 17,316블록(hit=16,174 / read=1,142), GOOD 3,177블록(hit=3,177)이었다. 실행시간 412.502ms 대 14.578ms는 단일 측정으로, 캐시·시스템 부하 등에 따라 변한다.
검색 결과가 현재 같은 이유: 지금 데이터에서는 shop_id = 'S033'인 행도 4,182건이고, shop_id LIKE 'S033%'인 행도 4,182건이며, S033으로 시작하지만 S033이 아닌 코드의 주문은 0건이었다. 그러나 일반적으로 LIKE 'S033%'는 S0331, S033A 등 추가 문자열로 이어지는 코드까지 포함할 수 있다. 지금 결과가 같다고 두 조건이 동등한 것은 아니다.
핵심
•
정확한 값은 =, 접두사 검색은 LIKE '값%'를 사용하자. 습관적인 와일드카드는 조회 의미와 인덱스 접근 방식 모두에 영향을 줄 수 있다.
참고·예외
•
와일드카드 없는 LIKE 'S033'은 이 실습 환경에서 Index Cond: (shop_id = 'S033')로 최적화되어 인덱스를 사용했으며 LIKE Filter도 남았다. 따라서 모든 LIKE가 인덱스를 못 탄다는 의미는 아니다. 접두사 LIKE 'S033%' 역시 Collation, text_pattern_ops/varchar_pattern_ops 같은 인덱스 연산자 클래스, 통계 등에 따라 다른 계획을 선택할 수 있다. 실제로 접두사 검색이 필요한 업무라면 LIKE를 =로 바꾸지 말고 적절한 인덱스 설계를 검토해야 한다.