1천만개든 1억개든 많은 양의 데이터가 한 테이블에 있다고 치자.
Date(datetime)의 컬럼에는 인덱스가 있고
Something(anytype)의 컬럼에는 인덱스가 없다.
where Something = xxxx order by Something ASC
이건 Something에는 인덱스가 없으니 전체 테이블을 검색할 거야.
그런데...
where Date = 오늘 AND Something = xxx order by Date DESC
이건 WHERE절에서 Date를 먼저 검색범주에 넣었으니 Date 인덱스가 활용되고, 오늘날짜의 데이터 내에서만 Something 전체 검색을 하겠지?
즉 앞의 Date와 order절의 Date 인덱스가 적절히 활용됨?
된다면 모든 컬럼에 인덱스를 걸면 아무래도 디스크 용량의 압박이 심하니 Date와 같은 범위 컬럼에만 인덱스를 주고, 모든 쿼리는 날짜 기간을 한정해서 검색할 범위를 줄이도록 한 후에
나머지 데이터들은 인덱스를 안 걸려고 하거든.
가능한 계획?
우선 시스템의 특성을 먼저 파악해야 합니다. read heavy system인지 write heavy system인지 read heavy라면 인덱스를 많이 사용하는것이 좋고 write heavy 라면 가급적 필요한 곳에만 인덱스를 하는게 더 좋습니다. 인덱스는 디스크용량의 압박보다는 데이터의 입력과 수정에 레이턴시가 길어진다는게 문제죠. write작업을 master쪽에 걸고 read작업을 slave쪽으로 걸고 replication쪽으로 인덱스를 좀 더 추가한다면 read, write양쪽에서 잇점을 가질수 있고요. OLTP와 OLAP를 혼용해서 쓰지 않아야겠죠.
날짜에만 인덱스걸고 나머지는 날짜로 필터된 데이터를 naive하게 검색하겠다는 아이디어는 그다지 좋은방법 같지가 않습니다. 하지만 특수한 경우에는 좋은 해법이 될수도 있겠지요.
그렇쿤요.