피드로 돌아가기
Inside SQLite’s Frontend: BETWEEN, OR, LIKE, and GLOB Optimizations
Dev.toDev.to
Database

Inside SQLite’s Frontend: BETWEEN, OR, LIKE, and GLOB Optimizations

SQLite가 BETWEEN, OR, LIKE, GLOB 연산자를 내부적으로 재작성하고 최적화 규칙을 적용해 인덱스 활용성 극대화

Athreya aka Maneshwar2026년 3월 24일8intermediate

Context

SQL 쿼리의 WHERE 절에 자주 등장하는 BETWEEN, OR, LIKE, GLOB 연산자들은 표면적으로는 단순하지만 내부적으로 복잡한 최적화 전략이 필요하다. 이러한 연산자들을 어떻게 처리하느냐에 따라 인덱스 활용 여부와 쿼리 성능이 크게 달라진다.

Technical Solution

  • BETWEEN 절을 내부적으로 두 개의 비교 조건(>= AND <=)으로 재작성: 인덱스가 양쪽 조건을 모두 만족할 경우 범위 스캔 수행, 하나라도 불가능하면 원본 BETWEEN 조건을 행마다 평가
  • OR 조건을 IN 절로 재작성: 동일 컬럼에 대한 다중 OR 조건(age = 20 OR age = 25)을 IN 절(age IN (20, 25))로 변환해 인덱스 활용 가능하게 변경
  • 서로 다른 컬럼의 OR 조건은 각 항을 독립적으로 분석: 각 OR 항이 인덱스를 사용할 수 있으면 별도로 실행 후 결과 병합, 일부 항이 인덱스를 사용할 수 없으면 전체 테이블 스캔 발생
  • LIKE/GLOB 패턴 매칭에 인덱스 적용 조건 설정: 좌측이 텍스트 컬럼이고 우측이 문자열 리터럴 또는 바인드 파라미터일 때만, 패턴이 와일드카드로 시작하지 않을 때만 인덱스 활용(예: 'A%'는 가능, '%A'는 불가능)
  • LIKE의 대소문자 구분 및 콜레이션 규칙 적용: 기본 ASCII 문자는 대소문자 구분 없으나 비ASCII 문자는 항상 구분, GLOB은 항상 대소문자 구분, 인덱스 활용 시 BINARY/NOCASE 콜레이션 일치 필수

Key Takeaway

SQL 연산자의 단순한 문법 뒤에는 인덱스 활용 가능 여부를 판단하는 엄격한 내부 규칙이 있으며, 쿼리 작성 시 이러한 변환 규칙과 제약 조건을 이해하면 의도하지 않은 전체 테이블 스캔을 피할 수 있다.


SQLite 기반 애플리케이션에서 WHERE 절에 BETWEEN, OR, LIKE를 사용할 때, 패턴이 와일드카드로 시작하지 않는지 확인하고, OR 조건이 동일 컬럼인지 검증한 후, 적절한 콜레이션(BINARY 또는 NOCASE)이 인덱스에 설정되어 있는지 확인하면 인덱스 활용 가능성을 극대화하고 쿼리 성능 저하를 방지할 수 있다.

원문 읽기