본문 바로가기
SQL/MSSQL

row_number 순서 뒤바뀜 현상

by forkballpitch 2017. 7. 3.
728x90
728x90

SELECT *
FROM   (SELECT Row_number()
                 OVER (
                   ORDER BY A.updatedate DESC)                 RNUM,
               CONVERT(VARCHAR(10), B.reservedate, 126)
               + ' ' + CONVERT(VARCHAR(8), B.reservedate, 114) ReserveDate,
          
               (SELECT CASE
                         WHEN Count(oid) > 0 THEN 'Y'
                         ELSE 'N'
                       END
                FROM   dbo.t_datalog WITH(nolock)
                WHERE  userid = 54
                       AND oid = A.oid)                        ReadYN     
     
        FROM   dbo.t_totaldata A WITH(nolock),
              dbo.t_board B WITH(nolock) on .............................................
        
 


1. rnum 자체가 이상하게 나오는 것은 아니겠죠?
  - 정말 그렇다면 버그라고 볼 수 있구요.
  - rnum 자체는 이상이 없으나 정렬결과만 흐트러지는게 아닐까 생각되네요.
2. 정렬 결과를 보장해 주는 것은 정렬 구문 뿐입니다.
  - 다른 구문을 통한 정렬 결과 도출은 언제든지 뒤바뀔 수 있습니다.
  - 맨 마지막에 정렬구문을 넣어 주시면 될 듯 하구요.
3. 정렬결과가 흐트러지는 이유는
  - 쿼리 변형에 따른 실행계획 변화 때문인 듯 하네요.
  - 스칼라서브쿼리가 맨 마지막에 수행되어야 하는데..
  - 인덱스가 없다보니 풀스캔으로 큰 비용이 예상되어 세미조인 형태로 변형된 게 아닐까 합니다.
  - 추측성 답변입니다. 직접 실행계획 확인하세요.
4. 혹시 rnum 사용이 페이징 처리를 하기 위함이라면?
  - 복잡한 계산식, 조인, 스칼라서브쿼리, 사용자함수 사용 등을 페이징 이후로 미루세요.
  - 선 가공 후 페이징 > 선 페이징 후 가공
5. 날짜 포멧 추출 부분이 복잡하네요.
  - 원본 : CONVERT(VARCHAR(10), b.reservedate, 126) + ' ' + CONVERT(VARCHAR(8), b.reservedate, 114) ReserveDate
  - 개선 : CONVERT(VARCHAR(19), b.reservedate, 120) ReserveDate

728x90
728x90