각각 테이블의  분포도나 크기, 인덱스 종류에 대한 내역이 없어 단정하기는 힘들지만...제 생각에는

인라인뷰 (SELECT Y.CD FROM TAB1 Y  WHERE Y.CD_KIND = ’2’ GROUP BY CD) 의 활용이 잘못되어 이부분을 튜닝포인트로 잡아야 될것 같습니다. 뭐 그래서  미션이 exists 서브쿼리겠지만요..^^;

이 인라인뷰의 역할은 cd_kind=2인 cd값이 추출하고 중복값을 제거하기 위해 group by를 했는데 실제 요구는 cd의 존재여부만 체크되면 같은 의미입니다. 더구나 CD_KIND같은 분포도가 좋지 못할 것 같은 결합인덱스 선두컬럼으로 인해 과도한 인덱스스캔이 발생하고 있고요.
결론은 많은 데이터를 상대로 불필요한 GROUP BY,  분포도가 좋지 않은 결합인덱스사용에 대한 튜닝?을 포인트로 잡아야 된다는 생각이 듭니다.

SELECT X.WARE_CD,count(*)
  FROM TAB2 X
 WHERE X.YMD = ’19990315’ 
   and exists ( SELECT ’X’ 
                  FROM TAB1 Y
                 WHERE Y.CD_KIND = ’2’
                   AND Y.CD = X.CD)
 GROUP BY X.WARE_CD ;

그래서 나온게 위의 쿼리네요..수정된 서브쿼리를 보면 불필요한 GROUP BY는 없어졌고 존재하는지 체크하고 빠져나오고 
TAB1의 불완전한 결합인덱스가 CD조건의 추가로 (TAB1_I1인덱스가 UNIQUE인덱스라면) 효율이 훨씬 좋아졌을 겁니다.아니라도 
ACCESS량은 줄었을 것 같구요.. 이상입니다.
뭐 어디까지나 테스트를 할 수 없는 상태에서 만든 제생각이니 제가 잘못 생각하고 있는 부분이 있다면 지적해주세요.

이런 글은 첨인데 함써보니 디테일한 설명을 하는 강정식님이 더욱 대단하다는 생각이 드네요^^