잡스런팁 몇가지
1. 물론 모르는 사람이 있겠나 싶지만..
select ~ limit 0,30;
하면 0을 기준으로 30개의 record 를 가져온다.
그리고 limit 30,30 을 하면 30번째 row offset 을 건너뛰고 뒤에 30개를 가져온다.
그러나 이 limit 은 인덱스 시킹을 하여 스키핑을 하는것이므로 실제 칼큐레이셔닝이 도는것과 마찬가지다.
따라 i/o 부하가 발생한다.
궁금하다면 데이터를 1억개 가량 삽입하고 limit 90000000,30; 을 때려보라 시간이 얼마나 걸리나.
이건 innodb 에 국한된것이 아니다.
이를 편리하게 넘나들기 위해서는 오라클의 rowid (rowcounting) 기능이 있다면 금상첨화겠지만.. 없으면 삽질해야한다.
2. hbs 에 사용된 기법중 한가지이지만 지금은 내렸다., 페이징쿼리시 number error correcting 중 골때리는 방식중 한가지가 있다 -_-
리스트의 최상위 pk를 기준으로 별도의 해당 페이지의 페이징 테이블에 인서팅하여 이값을 range selecting 을 통해 근접대 값을 sum적용하여 지워진 글에 대한 갯수를 구해온다.
정확하지는 않지만, 나름 외부로 티나지 않게 깨끗한 방법중 한가지였다.
문제는 정확하지가 않는다는것이다.
또한 게시물이 삭제될 경우 해당 range 에 prepare value를 삽입하였다가 나중에 pk가 리스트를 읽을때 근접 영역에 합산시켜버려야 한다.
별로다 -_-
3. PK (Primary Key)를 기준으로 select 를 해올때 편법적으로 negative numbering 을 사용하는 경우가 있다.
pk 를 -1 부터 시작해 음수로 반환시키는 방법이다.
그리고 별도의 no 값등을 통해 이를 서치하는 방법이다.
별문제가 없을것 같은가..
문제가 있다 -_-
대략 15만개의 레코드를 넘어서면 그 이전의 경우 pk가 아닌 다른 index 값 (예: no) 등을 통해 select 를 하면 order 방식을 삽입된 pk 의 순서대로 (그러니까 이경우는 정상이다) 로 가져오지만
그 영역을 넘어서면 mysql 은 이상동작을 하게된다.
무슨말이냐면 1000, 999, 998 식으로 select한 결과가 나와야하는것이 정상이다.
select ~ where no < 160000 limit 30;
을 때리면 요쯤까지는
159999, 159998, 159997, 159996 ~ 등 번호가 역순으로 잘나온다 생각하겠지만..
where no < 1000 limit 30; 을 때리면..
여기선 1,2,3,4 가 나온다는것이다 -_-
자체 인덱스 처리형식이 그렇다고 한다. pk 가 아닌 index 로 range selection 을 주지 않도록 신경쓰자 -_-
(0) 
(0)Posted by LeCieL