안녕하세요~
어떤 이벤트가 발생한 것을 기록하는 로그성 데이터 저장 테이블이 있습니다.
해당 테이블에 데이터는 일정 기간 넘어갈 경우(eg, 6개월) 삭제는 하고 있습니다만,
그래도 쌓인 데이터가 많아서, 일시 기준으로 범위를 잡고 페이징 처리를 하다보니 쿼리가 점점 느리지고 있습니다.
<< 테이블 스키마 >>
log_data (
log_id BIGINT,
log_dt DATETIME,
log_type VARCHAR
)
<< 조회 쿼리 >>
SELECT log_id, log_time, log_type
FROM log_data
WHERE log_time >= from_unixtime(123)
AND log_time <= from_unixtime(456)
LIMIT 500, 250
(시간은 실제 epoch 타임인데, 위에서는 임의로 넣었습니다.)
인덱스로 잡을만한 필드도 없는 상황인데, 쿼리 속도를 향상 시킬 방법이 있을까요?
생각해 본 트릭으로는, 로그일시 필드에서 날짜만 저장하는 log_date 필드를 새로 추가하고 여기에 인덱스를 걸어둔 다음,
이 필드도 검색 조건에 같이 추가하면 어떨까 하는 것입니다.
<< 테이블 스키마 >>
log_data (
log_id BIGINT,
log_dt DATETIME,
log_date INT,
log_type VARCHAR
)
<< 조회 쿼리 >>
SELECT log_id, log_time, log_type
FROM log_data
WHERE log_date >= 100
AND log_date <= 500
AND log_time >= from_unixtime(123)
AND log_time <= from_unixtime(456)
LIMIT 300, 100
아니면 그냥 바로 log_dt 필드에 인덱스를 추가하는 것도 문제가 없을까요?
이외에 다른 좋은 방법이 있는지 궁금합니다.
미리 감사드립니다~
log_dt 필드 값은 datetime 값이기 때문에 거의 모든 값들이 고유한 값을 가지고 있습니다. 그래서,
- 인덱스 내부적으로 B-tree를 사용하므로, 매번 insert 시 마다 밸런싱이 일어나서 성능이 저하되는 것이 아닐까?
- 추가로, 디스크 공간을 더 차지하는 것이 아닐까?
인터넷 검색 등으로만 알아본 얕은 지식이기에, 혹여나 잘못된 정보이면 바로 잡아주시면 감사하겠습니다~
-----
질문을 주시고 나서 다시 잠시 생각을 해보니, 제가 갖고 있던 의문점은 충분히 테스트가 가능할 것 같네요ㅎㅎㅎ
다음 주에 바로 테스트를 해보아야 겠습니다.
그리고 또, 각 테이블마다 PK를 추가하고 있었는데 (여기서는 log_id), 생각해 보니 이 값 또한
sequencial하게 증가하는 unique 값이라 datetime 값과 동일/유사한 성격이라고 볼수 있을 것 같습니다.
질문 주신대로 PK에 인덱스 추가되는 것과, 제가 datetime필드에 인덱스 추가하는 것에 차이가 없는 것 같네요.
댓글 감사드립니다~