서브쿼리에도 board_id 조건이 들어가야 하는 건 아닌지?
테이블의 인덱스가 어떻게 구성되어 있는지?
board_id 관련 인덱스는 있는지?
1. 스캔 범위 최소화
 - ROWNUM <= 1 조건을 추가해 보세요.
2. 테이블 랜덤 엑세스 제거
 - COUNT(item_id) 대신 COUNT(item_parent_id) 나 COUNT(*) 로 바꾸세요.

친절한 답변 감사합니다.

SELECT 

T1.AAA,

T1.BBB,

T1.CCC,

CASE

WHEN 

(

SELECT COUNT(*)

FROM FAQ_ITEM_T

WHERE 1=1

AND BOARD_ID = 'TEST0001'

AND ROWNUM <= 1

AND ITEM_PARENT_ID=T1.ITEM_ID

)

> 0

THEN 'Y'

ELSE 'N'

AND AS HAS_CHILD

FROM FAQ_ITEM_T T1

WHERE BOARD_ID = 'TEST0001'

AND 이 후에 검색 조건(날짜, 삭제여부 등)이 들어 오는 목록 쿼리 입니다. 

;

위와 같이 수정해 보았으나, 속도는 동일(느리게)하게 나오고 있습니다.

해당 테이블의 인덱스가 검색 조건에 따라 적용되게 끔 되어 있습니다.

IDX1 검색 조건이 날짜가 들어 오면 REG_DATE에 인덱스가 걸림.

IDX2 검색 조건이 댓글여부가 들어오면 ITEM_PARENT_ID에 인덱스가 걸림.

다만, 

ITEM_ID(PK) 및 ITEM_PARENT_ID 에는 INDEX 가 우선 지정되어 있습니다.

위의 내용만으로는 경우의 수가 너무 많을 것 같은데

어느 부분을 확인해 보면 좋을까요... ㅠㅠ

서브쿼리 개선해 드렸는데 전혀 효과가 없다면?
성능저하의 원인이 서브쿼리가 아닌 다른데 있는게 아닌지?
아니면 서브쿼리 인덱스를 제대로 이용하지 못하는 것은 아닌지?
7천건이면 적은 건수인데? 혹시 전체건수가 아닌 조회 건수인지?
페이징 처리는 하고 있는지?(서브쿼리를 페이징 처리 후로 미뤄 보세요.)
item_id 는 PK 인가요?
board_id 가 기본 조건인듯 한데? 이에 대한 인덱스는 있는지?
인덱스가 검색 조건에 따라 적용되게 끔 되어 있다는데? 어떻게 적용한 것인지?
어떤 조건이 어떻게 들어오는지? 조건은 가변적인지?
동적쿼리로 구성되나요?
바인드 변수가 사용되나요?

스칼라 서브쿼리인 case when 의 조회를 주석처리한 다음에도 느린가요? 

실행계획을 올려주시면 도움이 될겁니다.