처음에 인덱스를 잡지 마시고 ... 작업이 완료된후 인덱스를 잡아보세요.

@리자 +1

예전에 아주 오래된 이야기입니다만,,
그리고, 다른 이야기 일 수도 있지만요..

C언어 시절에 속도와 메모리는 아주 중요한 문제였습니다.
가령 루프를 돌릴때,
특정한 것들은 미리 값을 먼저 가져오게 하는 방법이라든지...해서
코딩을 슬림화 하는 것이 관건이었죠.

가령 루프안에 Where creat_dt = char(시스템날짜 가져오기)... 이런식이면
계속 같은 시스템 날짜를 가져오기 위해 연산을 해야 하므로
속도에 엄청난 차이가 있는 거죠.
그리서,
날짜가 특정 되어 있다면, 날짜 = 특정날짜 가져오기 해서 미리 변수에 불러온 다음
Where creat_dt = char(날짜)

예를 들었는데..

이런것들이 수백만 줄의 코드 안에 많을 수 있다는 거죠...

아..
비 전문가가 짜내서 주저리주저리 하려니 어렵네요..ㅋㅋ

나머지는 @리자 언니한테 패쑤...

행복한 하루 되세요..

국내에 몇 안되는 초대용량 - 1초에 2G - 씩 나오는 데이타를 처리한적이 있습니다.
DB 전문가는 DB 로 가능하다라고 해놓고는 내놓은 방법이 DB 테이블을 시간단위로 만들어 처리하는 방법이더라구요
정확한 용어는 모르지만 외부에서 보기에는 하나의 DB 테이블이지만 내부적으로는 파일들이 분리되는 그런 방법이 었던거 같습니다.
결국 되기는 되는데 관리가 너무 힘들어 포기했었죠.
DB로 되는거면 하면 되는데 DB의 한계를 넘어가면 꼭 DB만 고집할 필요는 없어 보입니다. ^^

저도 주저리 주저리 되었구요 ㅋㅋ
일단 입력 데이타의 건수는 그렇다 치고 사용자가 가져가는 데이타의 검색 범위가 어떻게 되고 키값이 어떻게 되냐에 따라 정책이 바뀌어야 할거 같습니다.

데이터가 많은 DB는 사실 딱히 획기적인 솔루션이 별로 없습니다.
하드웨어 사양을 높이고 인덱스 설정을 잘 하는 방법이 대부분이죠.
그것도 안되면 오라클이나 postgreSQL 처럼 좀더 고가용성 DB로 올리거나
select 속도가 중요한지 insert/update 속도가 중요한지에 따라 특성에 맞는 DBMS로 교체하거나
원장 DB 테이블에서 별도로 view를 만들거나 view 형식으로 동작할수 있는 테이블을 만들어서 로직으로 처리하는 방법이 대부분인것 같습니다.

물론 서버도 어느정도 받쳐줘야 하는건 당연한거지만요,
서버의 성능을 무한 확대할수없는 상황에서는

실데이타는 join 을 해서 가져오게 처리하는것도 방법입니다.

데이타가 몇십만건으로 6초가 나온다면 튜닝을 하셔야 합니다.

io가 잦은 db는 인덱스를 최소화 하시고,

잦은 io를 위한 테이블과 검색을 위한 테이블형태로

검색용 테이블을 분리하시는게 나을겁니다.

----

테이블만 보고 튜닝하기보다는
데이타의 흐름상 묶여야 하는것과 분리해야 하는것을 판단해보시는게 좋을듯 합니다.

@플래토 작성자님이 상세한 내용을 주시면 같이 토의해 보는것도 좋은거 같은데요 ^^

대용량을 스트레스 없이 쓰려면 오라클 써야 하구요.
구조가 어떤지는 모르겠지만 60만건에 6초면 심각하게 느린겁니다.

저 같은 경우는 쿼리는 최대한 단순하게 하고 각종 연산은 php에서 해결합니다.

@드림러 DB 와 웹서버가 한서버이거나, DB 는 바쁜데 웹서버는 논다고 하면 그 방법이 맞겠지요 ^^
그렇치 않다면 적절한 부하 분산이 필수라고 생각됩니다.
물론 님은 아니겠지만 DB 쪽이 약한 웹 개발자들이 뭐든지 웹단에서 처리하려고 하는 경향이 심해서 노파심에 댓글 달았습니다.

60만건 검색이면 인덱스없어도 금방 나와야할텐데요.
디비에서 60만건은 많은 데이터가 아닙니다.
데이터를 계속 밀어넣는데 테이블락이 걸려서 select 쿼리가 대기타고 아닌지... 그리고 데이터가 계속 바뀌는 중에 디비캐시를 늘리는건 오히려 속도를 더 느리게 할 수 있습니다.

조인되는 부분이나 검색의 조건이 되는 부분에는 반드시 인덱싱을 해주어야 빠릅니다.
인덱싱으로 문제해결된다에 한표를 던져봅니다.