start_date에 인덱스가 있는지 모르겠습니다만,

없다면 풀 테이블 스캔을 하게 됩니다. 풀테이블 스캔시에 읽혀지는 row부터 특정갯수의 row가 읽혀지면 읽혀진것부터 화면에 뿌리게 되구요..

흔히 토드나 오렌지에서 빨리 읽혀지는 것처럼 '보이는' 것은 먼저 읽혀진 row부터 화면에 뿌려주기 때문에 '체감상' 그렇게 보입니다(기본이 10개 단위던가...). 전체 row를 다 읽는다면 group by 해서 읽는 속도랑 비슷하게 느껴질겁니다.

group by를 하게 되면 일단 테이블을 다 읽어야 하고, 그 다음에야 group by를 하게 됩니다. 그러니 '테이블 다 읽는 시간'+group by 를 하게 되니 체감상 훨씬 늦게 나타나는 것처럼 보이게 됩니다.

또 한가지 가능성은 start_date에 인덱스가 있는 경우 그냥 읽을 경우엔 start_date의 인덱스를 이용하여 index_range_scan을 수행하나 group by로 인해 plan이 변경될 수도 있습니다(흔한 경우는 아니지만 잘못된 통계정보로 인한 오류로 그럴수 있고, 옵티마이저가 group by의 cost를 높게 책정할 경우 변경될 가능성이 있습니다. start_date에 인덱스가 없는 경우라도 group by로 인해 code_1의 인덱스를 full scan할 수도 있겠네요...). 자세한건 플랜을 봐야 알수 있습니다.

이런 경우라면 통계정보를 새로 생성하거나, 인덱스 힌트를 추가하여 바로 잡을 수 있습니다.

먼저 두가지 경우의 PLAN을 보시고 변경여부를 확인해보시기 바랍니다. 

group by의 경우 전체 범위 처리를 하게 됩니다.

즉 해당 table을 full로 스캔한 후 운반 단위를 만들어 데이터를 이동하여 화면에 뿌리게 되죠...

실행계획을 봐야 알겠지만.. 제 생각에 code_1에 index가 있다고 하더라도... 그 인덱스가 적용되어 실행되는지도 봐야 할거 같구요...

그렇지 않다면... hint로 강제 적용이 가능합니다.

제 생각에 데이터 분포도는 확실히 모르지만... code_1+start_Date 의 복합 인덱스를 생성하여 실행계획 분석 후 performance 를 분석해 보심도 어떻지요... ^^;;

인덱스 테이블만의 스캔은 일반 테이블을 full scan 하는 것보다 비용적인 측면이나 i/o 측면에서 유리 합니다. 인덱스 테이블의 사이즈가 일반 테이블보다 작기 때문이죠...

참조 바랍니다.