19초가 걸리는 쿼리문을 봐야 어디를 수정할 수 있을지 알 수 있을 것 같은데요..

어떤 조건에서 검색이나 정렬을 사용하는지를 알아야 인덱스 구성이나 다른 빠르게 할 방법이 있을지 알 수 있을 것 같습니다.

신이 아닌 이상 직접 보지 않으면 모릅니다. 

다만 예상만 가능 하겠지요.

140만건 이라는 것은 많은 것일 수도 있지만 140만건 뿐이야? 정도일 수도 있습니다.

단순 셀렉트를 생각 하면 이제 100만건 단위는 많은 것도 아닙니다.

그럼 이를 지연 시키는 요소가 있다는 이야기 뿐이 안됩니다.

쿼리를 사용 시에 지연 시키는 요소로 가장 먼저 생각 해야 하는 것은 풀 스캔 인가? 입니다.

대표적으로 if 문은 풀 스캔 입니다.

풀 스캔이란 로우를 가져온 다음에 전체 적으로 다시 한번 스캔을 하는 작업니다.

동일하게 union 도 마찬가지입니다.

그리고 페이지리스트 단위가 들어가는 거 보니, 전체 로우에 대한 all count 를 한번 더 하시는것 같은데, 

이것도 방법에 따라서 속도에 영향을 줍니다.

쿼리 퍼포먼스는 정답이 없는 만큼 경험이 중요 합니다.

어지간해서는 쿼리 튜닝으로 속도를 확 줄일 수 있을 거라 생각 듭니다.

혹시 nosql 도입까지 생각 중 이시라면, nosql 도입은 차선책이고, 먼저 튜닝 부터 진행해 보셔야 할 거라 사료됩니다.

우선 쿼리 앞에 explain 을 붙이면 여러 정보가 나옵니다.

explain에 대해 검색해보시고 결과에 따라 쿼리튜닝을 할 수도 있고(join 방식을 바꿔서 select 대상 수 자체를 줄이는 방법이 있습니다) 

구조를 바꿔야할 수도 있고 그렇습니다.

index가 걸려있다고 다 빠른건 아니고 index가 적용되는건 아닙니다. 그리고 3개의 필드에 대해 검색을 한다면 3개의 필드를 묶어서

index 를 걸어줘야 제대로 된 효과를 볼 수 있습니다. 

index된 필드의 값이 3개 이하라면 (a, b, c 만 있는거라면) index 안거는게 오히려 좋구요. 

1억4천만건 들어있는 데이터가 있는데 1, 2초 안걸립니다. 구조를 어떻게 만드느냐가 관건입니다.