테이블에 풀텍스트를 생성하려면 그 테이블에 PK(또는UK) 컬럼이 반드시 존재해야 한다.
이는 검색해서 결과가 어느 행인지 알려줘야하니 당연하다고 본다.
그렇다면 풀텍스트 검색을 할 때 PK에 대해서 옵티마이저가 인덱싱을 할까 안할까 궁금하다.
뭔 소리냐면
테이블 구조가 아래와 같다고 가정하자
Number(PK)
Category1 : 음식, 자동차, 직업
Category2 : 피자, 햄버거 / 승용차, SUV, 트럭 / 백수, CEO, 연구원
Title : 제목
Content : 내용
게시물 양이 많다면 Category1에 맞춰 별도의 테이블로 분리하는 게 맞지만 개발편의 및 통합검색를 위해서 무조건 저렇게 유지한다고 가정한다.
--------
SELECT TOP(10) * FROM Table WHERE Number < 1000000000
이렇게 조회하면 아주 빠르게 결과가 나올 것이다. 다음 페이지를 검색해보자.
--------
SELECT TOP(10) * FROM Table WHERE Number < (방금 전에 검색한 결과 TOP(10) 중에서 마지막 행의 번호)
이렇게 조회하면 다음 페이지에 해당하는 결과가 빠르게 나올 것이다. (OFFSET 방식으로 페이징 안하고 있음)
--------
Category1이 '음식'인 행이 아주 드문드문 몇 십개의 행 정도밖에 없다고 가정
SELECT TOP(10) * FROM Table WHERE Number < 1000000000 AND Category1 IN ('음식')
이러면 10개를 찾기까지 3억개의 행을 확인해야한다면 3억개의 Row를 읽어야하는 큰 문제가 나온다.
그럼 Category1, Number의 복합 인덱스를 만들어주어서 해결한다. (Number, Category1 순으로 만들면 Number가 이미 유니크하기에 아무 소용없다.)
-------
그럼 이제 본문 검색을 해본다.
SELECT TOP(10) * FROM Table WHERE Number < 100000000 AND FREETEXT(Title, Content)
이러면 Number가 가장 큰 값의 행부터 차례대로 풀텍스트 인덱스를 다 읽겠지만 결과가 10개만 나오면 되니 금방 끝날 것이다.
-------
SELECT TOP(10) * FROM Table WHERE Number < 1000000000 AND Category1 IN ('음식') AND FREETEXT(Title, Content)
이러면 어떻게 될까? FREETEXT에 해당되는 행은 많지만 Category1 '음식'에 해당되는 것은 최소한 3억개의 행을 읽어야 10개의 검색 대상이 나올텐데
이러면 거의 풀스캔에 가까워져서 성능 저하가 발생하지 않을까?
아니면 옵티마이저가 Category1, Number의 복합 인덱스를 활용해서 몇 십개의 행을 대상으로 삼고, 이 몇 십개의 행을 차례대로 읽어서 FREETEXT 조건에 부합되는 10개를 찾을 때까지만 읽어서 빠르게 될까?
결국 질문의 요지는 WHERE 절에 컬럼에 대한 인덱스와 풀텍스트 인덱스를 함께 써도 옵티마이저가 알아서 최적의 조건을 찾아 인덱스를 선택하는가?
댓글 0