SELECT count(*) FROM table WHERE type = 1 AND time BETWEEN 0 AND 9999999999999
type과 time은 인덱스 걸려 있음 단, type과 time은 unique하지 않음
DB에는 200만건 넣어놓고 테스트 중인데 수십초 걸릴정도로 너무 시간이 오래 걸립니다. 왜 오래 걸릴 수 밖에 없는지 설명해 주실분 계신가요?
type와 time에 인덱스를 걸었다는 것만으로 모든 것이 해결되지는 않습니다.
실제 실행계획을 보면 아마 인덱스를 사용하지 않고 있을 것 같네요.
예를 들어 type 과 time에 각각 인덱스를 걸었는데, type=1이라는 조건이 별로 변별력이 없다면...
query optimizer가 인덱스를 활용하지 않고 테이블의 200만건 데이터를 모두 scan할 수도 있습니다.
수십초가 걸린다면 아마 이런 상황일 가능성이 높다고 봅니다.
가장 간단하게는 type과 time을 아우르는 인덱스를 거는 방법이 있을 것 같습니다만,
구체적인 상황을 모르니 자세한 말씀 드리기는 힘드네요.
---- academic은 제 고등학교 때 동아리 이름입니다. academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
type에 걸려있는 인덱스가 혹시 type 하나에만 걸려있는게 아니지 않나요? create index i on table(c1,type) 형태면 도움이 안됩니다
explain 명령어 찾아서 분석해 보세요.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
type와 time에 인덱스를 걸었다는 것만으로 모든
type와 time에 인덱스를 걸었다는 것만으로 모든 것이 해결되지는 않습니다.
실제 실행계획을 보면 아마 인덱스를 사용하지 않고 있을 것 같네요.
예를 들어 type 과 time에 각각 인덱스를 걸었는데, type=1이라는 조건이 별로 변별력이 없다면...
query optimizer가 인덱스를 활용하지 않고 테이블의 200만건 데이터를 모두 scan할 수도 있습니다.
수십초가 걸린다면 아마 이런 상황일 가능성이 높다고 봅니다.
가장 간단하게는 type과 time을 아우르는 인덱스를 거는 방법이 있을 것 같습니다만,
구체적인 상황을 모르니 자세한 말씀 드리기는 힘드네요.
----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.
type에 걸려있는 인덱스가 혹시 type 하나에만
type에 걸려있는 인덱스가 혹시 type 하나에만 걸려있는게 아니지 않나요? create index i on table(c1,type) 형태면 도움이 안됩니다
explain 명령어 찾아서 분석해 보세요.
explain 명령어 찾아서 분석해 보세요.
댓글 달기