함수의 결과를 세컨더리 인덱스로 쓰는 것에 대한 의견들이 궁금합니다

Question

다음과 같이 세컨더리 인덱스를 구성하는 경우에 대한 견해가 궁금합니다.CREATE INDEX idx_combined ON my_table(COALESCE(a, b));a가 null이 아니면 a의 값을, null이면 b의 값을 인덱스로 삼으려는데아무래도 그때 그때 계산되는 값이다보니 성능 같은 문제로 지양되는 방식인지혹은 다른 문제점이 있는지 궁금합니다.(추가)다음과 같은 정렬을 하고 있는 상황입니다. ORDER BY CASE WHEN column1 IS NULL THEN column2 ELSE column1 END ASC, column2 ASC저 case 부분을 좀 더 개선하고자 function based index를 고민하고 있는 상황입니다.

Clickin · Answer

function based index는 해당 조건으로 검색하는 쿼리가 많을 때 사용하는 기법인데쿼리에서 무조건 where COLAESCE(a, b) &#61; #param.a# 로 검색하시나요??function based index는 위의 상황에서 매번 함수를 다시 조회하는 부담을 줄이기 위해 사용하는 기법입니다.미리 함수의 결과를 캐싱해두는 경우로 받아들이셔도 무방합니다.그냥 조회조건에서 where a &#61; #param.a# 조회 시 자동으로 b를 가져오겠다는 목적이면 만들어봐야 애초에 인덱스를 타지 않기 때문에 필요가 없습니다.

르매 · Answer

저런 인덱스가 필요한 상황이 없도록 테이블 설계가 되면 좋은데 .. 어쨌든 질문하신 것은 저런 인덱스를 만들면 인덱스 생성이나 변경 부하가 크냐는 것 같습니다.뭐.. 그 부분만 놓고 본다면 별 문제는 없습니다. 어차피 병목은 IO라서.. 그 정도 CPU 연산은 깃털 같은 거죠.

세즈 · Answer

함수형 인덱스보다 union all로 푸는게 좋을거같은데.. 저는 oracle, mssql만 다뤄본 dba라 mysql은 잘 모르긴 하지만 union 으로 유도하는 쿼리 힌트같은건 없나요?

풍월상신(가니메디안) · Answer

인덱싱으로 인한 퍼포먼스 저하를 피하기 위한 인덱싱 회피 쿼리 기술도 있었습니다.간단하게는, a='a' 가 아니라, a=concat('a','') 이런 식으로요.인덱싱이 퍼포먼스 저하를 유발하는 상황에서는 인덱싱을 디저블하는 방법도 있다는 것.

초무쿤 · Answer

Function based index는 정말 어쩔수 없는 경우 최후의 보루로 쓰는겁니다.설계할때는 시용할일이 없어용. (처음부터 사용해야되는 상황이라면 설계상 뭔기 문제가 있는거니 설계를 힌번 들여다봐애 될듯 하네요)

함수의 결과를 세컨더리 인덱스로 쓰는 것에 대한 의견들이 궁금합니다

5개의 답변

기술 목록