곽순현 2013-10

동일시스템에서 동일쿼리로 비교된것이겠지요?
그냥 단순히 봐서는 DB를 긁어오는 웹페이지 or CS프로그램에서
자주 사용하는 컬럼을 인덱싱하는 방법이 있지 않을까요?
저도 잘 모르므로 다음분께 패쓰~

공팔이 2013-10

쿼리와 DB 최적화가 된 상태라는 가정하에서는 크게 나아질게 없을걸로 보입니다.
셀렉트된 Data가 움직이는 양은 동일하니까요.
저라면 아래의 순서로 검토해볼것 같습니다.
DB튜닝 -> 네트웍확장여부 -> Data압축

오프라인 2013-10

단순 컬럼(COLUMN)의 개수로만 양을 추정할 때 A테이블 행(ROW)의 길이가 20배가 됩니다.
그러면 입출력 단위인 BLOCK에 A테이블은 한개의 행이 들어갈 때 B테이블은 20개가 들어가게 됩니다

단순 조회(WHER/ORDER BY 없이)로 동일 수의 행을 조회 시 A테이블의 디스크 READ가 20배가
필요해서 I/O 병목에 걸릴 수 있습니다. 디스크 사용량(I/O)을 모니터링 해보시는 게 좋을 것 같습니다.

그리고 네트워크 사용량도 A 테이블에서 모든 컬럼이 아닌 B테이블 컬럼 수(5개) 만큼만 쿼리를 한다면
디스크 READ가 20배가 되어야 동일한 대역폭을 사용하게 될 것으로 생각됩니다.

milyman 2013-10

MS sQL 안에 있는 프로파일러를 사용해보세요.
어느 쿼리가 어떻게 IO를 일으키는지 볼수있습니다.

이동준 2013-10

윗글만 봐서는 정확히 파악이 되지 않지만..
전체 Row의 수가 중요하다기 보다는....
Select해서 뽑아 내야 하는 Row의 수가 중요합니다.

전체 Row의 수는 인덱스 단편화만 심하지 않다면  몇천만건이 넘어가지 않는다면 심각하게 문제가 되지 않습니다.
몇천만건이 넘어 간다면...

파티셔닝테이블로 물리 공간을 분산해서 저장하는 방식으로 테이블을 설계해야 합니다.

일반 상황에서 100~200만건을 한번에 Select할일이 자주 있지는 않겠죠,
그리고 MS-SQL 같은경우 Oracle과 달리 Select시에도 Lock이 걸립니다.
Select를 실행해 놓고 다른 Insert , Update , Delete가 실행되지 못하고 대기 하다가.. 롱트랜젝션으로
테이블 Lock을 걸어 버리기도 합니다...

필요한 만큼의 정보만 Where절로 걸어서 사용하시는게 답이 아닐까합니다.