테스트 사이트 - 개발 중인 베타 버전입니다

DB에서 데이터를 1000만개중에 10개 select하는거랑

· 12년 전 · 2236 · 3
DB에서 데이터를 1000만개중에 10개 select하는거랑
100개중에 10개 select하는거랑 비교하면
결론적으로 10개를 select 한다는면에서
해당 쿼리 처리가 서버에 미치는 부하량(처리 시간?)은
동일하다고 보면 될까요?
이 부분에 대해서 제가 이론적으론 잘 모르겠는데
전에 수천개 데이터를 페이징 없이 처리하면 웹페이지 로딩 속도가 굉장히 느렸는데
같은 데이터를 페이징을 나누니까 속도가 비교불가급으로 빨랐거든요.
그렇다면 DB select 처리시간도, 대상이 되는 테이블의 row 갯수랑은 완전 무관하게
select되어져오는 row의 갯수랑만 관련있는게 아닐까 싶어서
제가 생각하는게 맞는지 궁금해서 질문드립니다.

댓글 작성

댓글을 작성하시려면 로그인이 필요합니다.

로그인하기

댓글 3개

데이터가 쌓여진 상태 그대로 천만건과 백개에서 앞 10개를 가져오는것의 속도차는 거의 없을겁니다.
그런데 그 10개를 가져옴에 있어서, 정렬이 들어간다던가, 검색이 들어간다던가 하는 등의 뭔가 부가적인 처리가 있을 경우에는 천만건과 100개에서 각각 10개를 가져오는데에는 시간차가 많이 있겠지요. ^^
12년 전
select 문은 DB table에서 해당 field를 가져오겠죠. 문제는 from 테이블들과 where 조건문,having,group by
등에 따라 프로세스를 처리하는 쓰레드가 늘어 나고
row에 대한 한번의 처리 갯수 또한 처리량으로 소모하는 쓰레드도 늘어 난다고
생각되는데,,, 저는 개발자가 아니니 확실한건 아닙니다.
결과적으로 서버의 사양과 DB설계에 따라서 천차만별입니다.
그리고 검색되서 나오는 결과값이 얼마냐에 따라서 속도차이가 납니다.
1000만건이라도 무조건 느리지 않습니다.
오히려 적절한 설계에 인덱스의 효율성을 고려하면 0.0X 초 대의 속도로 뽑아오실 수 있습니다.
문제는 검색되는 결과값을 어떻게 하면 최대한 분배할 수 있는가의 문제겠네요.

예를 들면 1000만건 검색시 결과값이 100만건일때와 1만건일때는 확연히 차이를 보여줄겁니다.
일반적으로 페이징이 많을수록 뒤로갈수록 느려집니다.
최종적으로는 5000만건 이상일시에는 결과값에 대한 카운트쿼리만 날려도 느려질겁니다.
그렇지 않을려면 적절하게 설계를 해야되겠죠.

MySQL이 무료라지만 1000만건 정도에서는 0.0X초 정도가 나와야 정상입니다.

게시글 목록

번호 제목
5638
27321
5637
31931
31925
18979
5633
27316
27307
18976
5631
18974
31919
30803
31911
5625
5623
5620
27298
31904
31887
31884
18967
5616
5611
18963
5608
31881
5601
31866
31862
5599
5595
5592
24497
18958
31859
31855
18952
18946
18942
18939
18936
18933
5590
5586
18924
18915
18913
18908
27293
5583
5580
18895
18886
18880
5576
31840
30792
18869
18866
18862
18858
5569
5565
27287
18857
18855
18854
18847
18843
18841
18840
31825
18839
18835
18833
18832
18822
18820
5561
31806
18815
31830
18809
18807
18806
18803
18801
18800
18796
5559
18793
18791
5554
31780
31790
31758
24491
27284