그런데 어떤분이 같은구조의 테이블을 여러개 만드는것이

실제로는 포퍼먼스가 떨어진다고 하시는데요?

이글은 어떤 것을 기준으로 하는지 모르겠군요.

실제로 같은 테이블을 여러개 만든다고 퍼포먼스가 떨어지지는 않을 것입니다. 단지 테이블 측면에서 본다면 두개보다는 하나가 access 가 빠르겠지요. 600만개의 테이블이라면 불보듯 뻔합니다. 시스템 사양이 상당히 좋아야 할것입니다.

600만개를 그룹별로 나눠서...테이블을 분리하는 것도 방법일듯
싶네요.

그냥 제가 보고 배우고 지금까지 경험을 참고로 말씀드리겠습니다.

먼저 테이블을 단지 레코드가 많을것이라는 액세스 빈도가 많을것이라는걸 염려해서 분리하는것은 결론부터 말씀드리자면 권해드리지 않습니다.

 테이블을 여러개로 했을때 성능상의 잇점은 글을 쓸때, 삭제, 업데이트등일때 잇점(Locking)이 있을수있습니다만 전체적인 일관성 및 관리상의 효율을 떨어뜨립니다.

일반적으로 설계를 하면은 정규화를 하고(일반적으로 4정규화까지는 합니다)

설계가 제대로 됐다면 그뒤로는 물리적 시스템을 해당 설계에 맞춰서 구성을 해줘야한다고 생각합니다.

( 디스크가 40개짜리일경우 a테이블은 1,2,3,4번 디스크에 a의 a, b 인덱스는 5번 디스크에 c 인덱스는 6,7번 디스크식으로 ....: 물론 디스크가 40여개나 꽂히는 장비는 꽤나 비싸죠...아하하하... -,.- 죄송합니다... 방금 적은 예처럼 물리적 설계구성을하기 이전에 사실 인덱스나 쿼리튜닝을 제대로 해줘야겠죠. 디스크가 한개짜리면 물리적 구성에 대해서 신경을 쓸필요가 거의 없을꺼구요)

그리고 난뒤 특정부분에 대해서 정말 요구시간에 제대로 된 응답이 나올수없다는게 명확해진다면 그때 역정규화를 시행하게 됩니다.

디비구조를 잘 모르신다면 테이블을 여러개로 운영하는게 오히려 인덱스 특성이나 기타 dbms의 특성을 모르시는분에겐 유리한 경향이 있을수있으나 최대 600만명사용자를 고려했을때 인덱스나 기본 dbms의 특성을 모른채 운영은 거의 불가능하다고 말씀드릴수있습니다.