날짜 컬럼에 함수를 적용해 오늘 주문을 찾았더니 인덱스를 잘 못 씁니다. 조건을 어떻게 바꾸고 함수 인덱스는 언제 쓰나요?

인덱스에 저장된 순서를 탐색 경계로 표현할 수 있는지 확인해야 합니다. 컬럼을 매 행 함수로 변환한 조건은 기존 인덱스의 원래 값 범위와 직접 맞지 않을 수 있습니다. 같은 결과를 반열린 원본 범위로 표현할 수 있으면 우선 검토합니다.

동작 원리와 전제

타임스탬프를 날짜로 바꾸어 비교하는 대신 시작 시각 이상·다음 날 시작 미만으로 조회할 수 있습니다. 단, 시간대와 일광절약시간 때문에 하루를 무조건 24시간 더하는 방식은 틀릴 수 있어 업무 시간대의 경계를 계산합니다.

선택과 실패 처리

LOWER(email)처럼 변환 자체가 반복 질의의 의미라면 expression index나 생성 컬럼을 검토합니다. 함수의 결정성·collation·엔진 제약을 확인하고 쿼리가 같은 표현을 사용하는지 봅니다. 인덱스를 위해 입력 의미를 임의로 바꾸거나 문자열과 숫자의 암묵 변환을 방치하지 않습니다.

구체적인 사례와 검증

문자열 ID 컬럼을 숫자 파라미터와 비교하면 엔진이 컬럼을 변환해 인덱스 탐색을 어렵게 만들 수 있습니다. 파라미터 타입을 컬럼의 의미와 일치시키는 것이 새 인덱스를 추가하는 것보다 먼저일 수 있습니다. 날짜 조건도 서버 UTC 날짜와 사용자의 현지 날짜가 다르면 성능을 개선한 쿼리가 잘못된 행을 반환합니다. 경계 계산을 애플리케이션이나 DB에서 명시하고 같은 시간대 규칙을 테스트합니다. 함수 인덱스는 표현을 저장한 접근 경로이므로 함수·collation·정규화 정책이 바뀌면 재생성과 데이터 검증이 필요할 수 있습니다. 조회를 빠르게 하려다 비교 의미를 바꾸지 않겠습니다.

경계 시각·NULL·대소문자·시간대 변환의 결과 집합을 먼저 대조한 뒤 실제 읽기·계획을 확인합니다. 검색 가능 조건으로 바꿔도 선택도가 낮으면 scan이 더 쌀 수 있습니다. 인덱스 사용 여부만으로 성능을 판정하지 않겠습니다.