쿼리에 따라 다릅니다만 정석은 합치는 것입니다.

만일 79년도에 태어난 사람을 모두 뽑는 다면

10번의 쿼리를 실행해야 합니다.

그러나 이를테면 맨 끝자리에 따라 거의 100% 구별되어 쿼리가 사용된다면 한테이블을 나눌수도 있습니다.

그러나 그런 것을 묻는 것은 아닌듯 하고,

인덱스를 잘 관리하면 100만건이든 1000만건이든 상관없이 한 테이블로 두는 것이 나누는 것에 비해 떨어질 것이 없습니다.

만일 뒷끝자리에 따라 많이 구별되고 10만건이나되는 방대한 양이라 인덱스의 덕을 보기 힘들어 100만건 풀스캔을 해야되는 상황이라 하더라도, cluster를 써서 얼마든지 해결할 수 있습니다.

단지 기계에 램이 별로 없어 100만건 인덱스를 컨트롤 하는 것보다 10만건 인덱스 10개를 관리하는게 더 쉽다면 융통을 발휘해 볼수도 있겠죠.

마찬가지로 행여 update가 많은 경우에 10만건씩 10번할때가 훨씬 빨라서 속았다! 이럴수도 있는데

10번으로 나눠서 update해보면 똑같습니다.

오히려 transaction으로 싸려면 차라리 큰놈 하나가 나을수도 있습니다.

물론 roleback segment가 잘 관리되어 있지 않으면 segment가 없다고 징징거려서 나눌때가 좋았다고 머리를 벅벅긁을수도 있겠습니다만....

먼저, 데이터를 어떻게 사용을 하는지 확인을 해야 합니다.

데이터를 추출하는 쿼리의 결과 집합이 반드시 1건이라면 나누는 것은 별의미가 없지요...

하지만 추출조건이 서울에 있는 사람하면 여러개로 나누어 놓은 테이블은 동시에 읽는다면 효과가 있겠지요...

물론 데이터를 나누는 조건은 좀 생각을 해야 겠지만요...

데이터를 나누는 것은 많은 양의 데이터를 추출할 때 패러럴 쿼리를 이용하기 위하여 사용하는 것입니다.