[공지사항 제외] ( ) 예 (v) 아니오
SELECT * FROM `documents` WHERE `module_srl` IN (?) AND `status` IN (?,?) ORDER BY `list_order` DESC LIMIT 20
[공지사항 제외] (v) 예 ( ) 아니오
xml 쿼리 보니까 s_is_notice 같은데 아래와 같이 되겠죠.
SELECT * FROM `documents` WHERE `module_srl` IN (?) AND `status` IN (?,?) AND `is_notice` = ? ORDER BY `list_order` DESC LIMIT 20
후자는 is_notice 때문에 DB손해보험이 힘드네요.
그렇다면 이건 어떨까요?
board view 에서 글 목록보다 공지를 먼저 가져오네요, 그럼 is_notice = Y 해당된 document_srl 값들은 확보 했습니다.
그럼 쿼리를 이렇게 바꿀 수 있습니다.
[공지사항 제외] (v) 예 ( ) 아니오
SELECT * FROM `documents` WHERE `module_srl` IN (?) AND `status` IN (?,?) AND `document_srl` NOT IN (?) ORDER BY `list_order` DESC LIMIT 20
-
글 쓰는 김에 한 가지 더요,
첨부한 getDocumentNext.xml 보면 서브 쿼리가 잘못 해석되는 것으로 보입니다.
WHERE `document_srl` IN (12, 56) 와야 할 자리에 다른 조건이 들어옵니다.
xml 파싱하면서 변수를 잘못 처리해서 중뷁으로 ON 조건 같아요.
그롬 저눈 이만..
1. is_notice = 'N' 조건이나 document_srl NOT IN (...) 조건이나 목록에서 일부 게시물을 제외해야 하기 때문에 인덱스 스캔만으로 처리하기 어려운 것은 마찬가지입니다.
현재와 같은 is_notice = 'N' 조건은 특정 사이트에서 필요시 is_notice를 포함하는 복합인덱스를 생성하여 비교적 쉽게 해결할 수 있는 데 비해, document_srl NOT IN (...) 조건은 그러한 최적화의 여지마저 없는 막다른 길입니다. 따라서 개선이 아닌 개악이라고 생각됩니다.
2. 서브쿼리 안에서 참조하는 documents 테이블은 조인한 것이 아니고 해당 서브쿼리가 참조하는 유일한 테이블이므로, 조인 조건을 명시할 수 없습니다. 즉, 7~9줄은 무의미하므로 누락되는 것이 맞습니다. JOIN ... ON ... 으로 표현되는 조인 조건이 아니라 WHERE ... 로 표현되는 일반적인 조건이라면, 16~18줄의 <conditions> 안에 작성해야 합니다.
이 쿼리의 해석에서 오류가 발생한 부분은 L.document_srl != R.document_srl 조건이 조인 안팎에 중복으로 들어간 것입니다. 서브쿼리의 구조는 사실상 <query>와 동일하다는 전제 하에, 해당 조건은 서브쿼리 안의 WHERE ... 부분에 들어가는 것이 맞고, 이러한 태그 구조에서 ON ... 조건을 표현할 방법은 없어야 합니다. 이 문제는 패치해야겠네요.
패치를 하더라도 현재의 XML로 원하시는 결과를 얻도록 해드릴 수는 없습니다. 3개의 <condition> 중 8줄은 17줄 자리로 가야 하고 (해석 오류 때문에 이 조건이 중복으로 나오겠지만, 그건 패치하면 되고), 17줄은 28줄 전후로 옮겨야 ON ... 조건과 동일한 효과를 거둘 수 있을 거예요.