게시물 리스트를 뿌려줄때select ?? from 테이블 order by 정렬필드 limit x,x;이렇게 하고 있습니다.정렬필드는 double 8바이트 형이고 계층 구조는 이상없이 잘 되네요;이렇게 된 상황에서 100만 게시물을 넣는다해도테이블을 나눌 필요가 없는지요?
동시 쿼리수가 얼마인지 잘 모르겠지만
100만 정도라면 나눌 필요는 없다고 생각합니다.
음 셀 600에 64Mb 레드헷 9 에서
40만 게시물에서
첫페이지의 '쿼리만' 0.00? 초
후반부 페이지는 서버가 맛이간건지 간혹 30초가 걸리고
주로 5~6초 정도 걸립니다.
수정(방금 optimize table을 한번 해주니 5~6초 걸리던것이 optimize 직후에 한 테스트에서 23초 그후부터는 2.3초 정도 네요)
인덱스는 정렬필드 하나에대해 해줬구요
아직 검색같은건 생각도 못하고 있네요
검색필드는 double 형인데;; 이것때문에 느린건지
서버가 구형이라 그런건지..
제 기대보단 많이 느리네요;
쿼리를 정확히
select ?? from 테이블 order by 정렬필드 limit x,x;
라고 작성하셨다면, 처음에는 빨르고, 후반부에 시간이 많이 걸리는 것은 LIMIT 때문에 그렇습니다.
LIMIT 200000, 10
이렇게 하면, return 되는 것은 10개 record지만, 실제 20만개의 record를 skip 해야 하거든요. 이 시간이 많이 걸리는 것이죠.
Optimize table 한 후 속도가 빠른 것은, 레코드를 정리해 주어서 레코드간 이동이 빨라진 것일 수 있습니다. 그 후부터 2.3초인 것은, 버퍼로 데이터가 올라와서 빠른 것일 수 도 있구요.
음. 옛날에 테스트 할 때는 fixed length table의 경우, LIMIT 1000000, 10을 주더라도, 레코드 길이가 고정되어 있으므로, 레코드 길이 x 100만하면, 100만 번째 레코드 위치를 알 수 있으므로, 레코드를 금방 가져온 것으로 기억하는데, 요즘 버전에서는 안 되는 것도 같구요.
레코드 수가 40만 개더라도, 게시판이 여러 개 나뉘어져 있다면, WHERE에서 board_no 등을 INDEX로 걸면, 레코드 수가 나뉘어 지므로, 큰 문제는 없다고 생각되는데요. 그렇다고 해도, 정말로 게시판 하나에 40만개 레코드가 있다면 속도가 그 만큼 걸리기는 하겠죠.
해결책은 하드웨어 사양을 늘리시고, Query Cache 등을 이용해서 쿼리 결과를 캐시로 저장하시는 것이 좋겟습니다.
그런데 일반적인 경우, 마지막 페이지의 게시물을 읽는 경우는 드무므로 그냥 사용하셔도 될 듯 하구요.
그럼 안녕히 계세요.
LIMIT 이 간편해서 좋기는 한데, 위의 허정수님 말씀처럼 많은 데이터가 있을 경우는 오히려 양날의 검의 되어버립니다.
WHERE 절로 처리해버리시는 것이 좋을 듯으로 보입니다.
예를 들어
SELECT ... FROM 게시판
WHERE 게시물번호 BETWEEN ? AND ?
AND 게시판구분코드 = ?
....
이런식으로 쿼리를 ANSI SQL 하게 만들어주시고, 인덱스는 게시판구분코드 + 게시물번호 식으로 잡아주시는 것이 좋을 듯 합니다. 그럼 이만...
