뭔가 제목을 깔끔하게 만들고 싶은데ㅋ
좀 추상적으로 적었네요ㅎ

예전 300만건 게시판이라고 해서 hatelove 님이 만들었던 기법이 있습니다.
일정 primary key 범위 내의 "실제 존재하는 count 개수"를 따로 저장해 놓았다가 쓰는건데요
이를 이용한 엄청나게 빠른 게시판이 나왔었습니다.

300만건이어도 어디서 접근하든 거의 동일한 속도로 페이지가 출력되어서
신선한 충격이었습니다.

오늘 오랜만에 찾아보니 그 분의 사이트는 안 보이지만 -_-;;
http://levin01.tistory.com/1080 에 기법이나 구현은 잘 설명되어 있네요

mysql 에서 가장 퍼포먼스 영향을 많이 받는 것 중 하나가
limit x, y 라고 알고 있는데요 이 방법을 쓰면 특정 영역별로 인덱스를 더 걸어줘서
더 선택도(selective)가 높아지게 됩니다.
x 값 위치 계산을 위해 mysql 이 맨 처음부터 계산할 필요가 없어지니까요.

당연히 무지막지한 성능향상이 있었구요.

xe 는 상대적으로 더 큰 성능향상이 예상되는데요 이유는 다음과 같습니다.

1. xe 는 rewrite_rule 로 문서 번호만으로 접근하는 경우가 많고
    문서 번호만으로 페이지 값까지 유추해 내는 작업이 자주 생기는데
    이 때문에 한층 더 느려지는 것으로 알고 있습니다.
    page 파라미터가 안 넘어올 떄가 많으니까
    limit x, y 에서 x 값마저 모른다는 뜻이죠. 다른 게시판들은 이 값은 그래도 알고 시작하는데
    xe 는 이 값마저 추가적으로 계산해서 얻는 경우가 많습니다.

2. 또 한 테이블에 문서들이 같이 모여있기 때문에
    document_srl 값이 빠르게 증가하는 경향이 있습니다.
    다른 테이블별 게시판보다 기본적으로 선택도가 낮아질 수밖에 없는 단점이 있습니다.



xe 에도 이 기법이 쓰이면 mysql 부하가 주는건 물론이고
cpu 사용률도 낮춰서 전반적인 속도가 훨씬 빨라질 것 같은데요~

추가적인 개수 저장용 테이블이랑 document 테이블에 인덱스 필드를 추가해야 하지만
그 가치는 뽑고도 남는다고 보여집니다.

다른 분 의견은 어떠신가요?


oracle 에서는 db 단에서 이미 내부적으로 이런 것을 다 제공한다고 들었습니다.
정말인가요? -_-;;;;