CREATEDATE에 clustered index를 생성하시고, USER_ID에 nonclustered index를 생성하시는 것이 기본적인 방법이겠습니다.

로그테이블에 인덱스를 걸지 말라고 하는 것은 insert 시점에 인덱스의 유지를 위해 발생하는 cost를 최소화하고자 하는 것인데, 관리툴 등으로 조회를 하면 모든 데이터를 읽어들여야 하는 문제가 발생하므로 해당 data를 복사하여 별도로 조회를 위한 환경을 만들지 않는 이상은 index를 생성하는 것이 맞겠습니다.

윗분 말씀이 맞구요 ..

추가로 덧붙이자면

인덱스도 데이터의 일부입니다. 특히 로그성격의 데이터가 100만건 1000만건을 예상하신다면 .. ( 몇달안에 .. ?? ) 인덱스도 그만큼 SIZE 가 커져서 공간을 잡아 먹고 .. 쌓이면서 공용 리소스 CPU , I/O 등 .. 을 가져가기 때문에 고려를 해야하구요 ...

조회라는 서비스가 사용자가 ( 일반 유저 ) 아니고 관리자라면 ..

DB 자체를 분리해 보는 방안도 좋을꺼 같습니다. ( log 쌓는 DB를 따로 두는거죠 .. 물리적 독립이 가능하다면 더 좋을꺼 같습니다. )

여러의견 감사드립니다. ^^

근데.. 하루에 100만건정도 쌓인다면 인덱스를 안걸어야 겠죠? ㅡ,.ㅡ

일단 로그테이블은 유저단에서는 select가 안되는 부분이니 

인덱스를 안거는 방향으로 해야겠네요. 인덱스 건 상황에서 데이터가 많이 쌓여버리면

cpu나 i/o에 부담이 많이 될것 같아서요.. 정기적으로 로그를 삭제하는 정책을 만들어서 

관리단에서 select할때 부담을 좀 줄이는 방향으로 해야겠네요