이 특정 중복 파생 테이블에 대해 주문이 보장되지 않을 가능성이 있습니까?

나는 Lukas Eder와의 트위터 대화 에서이 질문을 우연히 발견했다 .

올바른 동작은 가장 바깥 쪽 쿼리에 ORDER BY 절을 적용하는 것이지만 여기서는 가장 바깥 쪽 쿼리에 DISTINCT, GROUP BY, JOIN 또는 다른 WHERE 절을 사용하지 않기 때문에 RDBMS가 왜 내부 쿼리로 정렬 된 수신 데이터?

SELECT * 
FROM (
    SELECT * FROM table ORDER BY time DESC
) AS t

PostgreSQL에서이 예제를 실행하면 최소한 내부 쿼리와이 파생 테이블 예제 및 동일한 결과 집합에 대해 동일한 실행 계획이 제공됩니다.

따라서 Planner는 중복되거나 내부 테이블의 결과를 통과하기 때문에 가장 바깥 쪽 쿼리를 단순히 버릴 것이라고 가정합니다.

아무도 이것이 그렇지 않을 것이라고 생각합니까?

대부분의 데이터베이스는 ORDER BY하위 쿼리에서 다음 중 하나 라는 사실에 대해 매우 분명 합니다.

• 허용되지 않음 : 예 : SQL Server, Sybase SQL Anywhere ( TOP또는로 보완되지 않는 한 OFFSET .. FETCH)
• 의미 없음 : 예 : PostgreSQL, DB2 ( OFFSET .. FETCH또는로 보완하지 않는 한 LIMIT)

다음은 DB2 LUW 매뉴얼 (강조 광산)의 예입니다.

부속 선택의 ORDER BY 절 은 조회가 리턴 한 행 순서에 영향을 미치지 않습니다 . ORDER BY 절은 가장 바깥 쪽 fullselect에 지정된 경우 리턴 된 행의 순서에만 영향을줍니다.

PostgreSQL과 마찬가지로 표현은 매우 명시 적입니다 .

정렬을 선택하지 않으면 행이 지정되지 않은 순서로 반환됩니다. 이 경우 실제 순서는 스캔 및 결합 계획 유형 및 디스크 순서에 따라 달라 지지만 의지하지 않아야합니다 . 정렬 단계가 명시 적으로 선택된 경우에만 특정 출력 순서를 보장 할 수 있습니다.

이 사양 ORDER BY에서 파생 테이블 의 절에서 생성 된 순서 는 우연히 발생하는 것으로 예상되는 순서 (사소한 예에서는 대부분의 데이터베이스에서 발생하는 순서)와 일치 할 수 있지만이 방법을 사용하는 것은 현명하지 않습니다. 이.

DB2에 대한 참고 사항 :

특히, DB2에는 알려진 기능이 적ORDER BY ORDER OF <table-designator> 으며 다음과 같이 사용할 수 있습니다.

SELECT C1 FROM
   (SELECT C1 FROM T1
      UNION
    SELECT C1 FROM T2
    ORDER BY C1 ) AS UTABLE
ORDER BY ORDER OF UTABLE

이 경우 파생 테이블의 순서는 가장 바깥 쪽 SELECT에서 명시 적으로 재사용 할 수 있습니다.

오라클에 대한 참고 사항 :

수년 동안 오라클은을 OFFSET사용하여 페이지 매김 을 구현하는 관행 이었으며 파생 테이블 을 주문한 후에ROWNUM 만 합리적으로 계산할 수 있습니다 .

SELECT *
FROM (
  SELECT rownum AS rn, t.* -- ROWNUM here depends on the derived table's ordering
  FROM (
    SELECT * FROM table ORDER BY time DESC
  ) t
) t
WHERE rn BETWEEN 10 AND 20

적어도 ROWNUM쿼리에 존재 한다면, 미래의 Oracle 버전은 기존의 모든 Oracle SQL을 거의 파괴하지 않기 위해이 동작을 중단하지 않을 것으로 예상 할 수 있습니다. 읽을 수있는 SQL 표준 OFFSET .. FETCH구문 :

SELECT * FROM table ORDER BY time DESC OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY

예. ORDER BY절이 없으면 출력 순서가 정의되지 않으며 쿼리 플래너는 사용자가 이것을 알고 이해한다고 가정 할 수있는 범위 내에 있습니다.

외부 쿼리는 순서를 지정하지 않기 때문에 정렬 작업을 피하기 위해 내부 쿼리에서 순서를 제거 할 수 있습니다 (특히 클러스터링 된 인덱스가 없거나 순서를 지원할 인덱스가없는 경우). 그렇지 않은 경우 지금 은 향후 버전에서 할 수 있습니다.

정의되지 않은 행동에 의존하지 마십시오. 특정 주문이 필요한 경우 ORDER BY적절한 장소에 조항을 제공하십시오.

정의되지 않은 동작의 문제입니다-당신을 위해 일하고, 나를 위해 일하고, HDD를 prod로 다시 포맷합니다.)

한 걸음 물러서서 어떤 의미에서든 옳다고 말할 수 있습니다. 제정신 RDBMS가 내부 선택에서 행을 재 배열해야 할 이유가 없습니다. 그러나 보장되지는 않습니다. 향후에 이유가있을 수 있으며 공급 업체는 자유롭게 할 수 있습니다. 이는이 행동에 의존하는 코드가 API POV의 주요 변경 사항이 아니기 때문에 공급 업체가 공개 할 의무가없는 변경을 자비로한다는 것을 의미합니다.

이 특정 중복 파생 테이블에 대해 주문이 보장되지 않을 가능성이 있습니까?

현재 존재하는 모든 Postgres (테스트중인) 버전에 대한 답변 은 다음과 같습니다. 아니요 -이 특정 쿼리에 대해. 정렬 순서가 보장됩니다.

Microsoft는 ORDER BY하위 쿼리를 허용하지 않기 때문에 SQL 서버 사용자는 불편할 것 입니다. 그럼에도 불구하고 Postgres에서이 간단한 쿼리에 대해서는 정렬 순서가 보장됩니다. ORDER BY는 하위 쿼리에 적용되며 외부 쿼리는 순서를 변경할 수있는 작업을 수행하지 않습니다.

매뉴얼은 집계 함수 장에서 많은 힌트를 얻습니다 .

또는 정렬 된 하위 쿼리에서 입력 값을 제공하면 일반적으로 작동합니다.

외부 쿼리 수준이 순서를 변경할 수있는 작업을 추가하지 않는 경우에만 해당됩니다. 따라서 간단한 경우에는 "보증 된"것이므로 SQL 표준의 지원을받지 않습니다. 추가 작업이 필요한 경우 Postgres를 무료로 재주문 할 수 있습니다. 의심스러운 경우 ORDER BY외부 에 다른 것을 추가하십시오 SELECT. (이 경우 내부 ORDER BY는이 간단한 쿼리에서 중복 노이즈가됩니다.)