Có thực sự là thứ tự sẽ không được đảm bảo cho bảng dẫn xuất dự phòng cụ thể này?

Tôi tình cờ gặp câu hỏi này trong cuộc trò chuyện trên Twitter với Lukas Eder .

Mặc dù hành vi đúng sẽ là áp dụng mệnh đề ORDER BY cho truy vấn ngoài cùng, bởi vì, ở đây, chúng tôi không sử dụng DISTINCT, GROUP BY, THAM GIA hoặc bất kỳ mệnh đề WHERE nào trong truy vấn ngoài cùng, tại sao RDBMS không vượt qua dữ liệu đến như được sắp xếp bởi các truy vấn bên trong?

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

Khi chạy ví dụ này trên PostgreSQL, ít nhất, bạn sẽ nhận được cùng một Kế hoạch thực thi cho cả truy vấn bên trong và ví dụ bảng dẫn xuất này, cũng như cùng một tập kết quả.

Vì vậy, tôi cho rằng Planner sẽ đơn giản loại bỏ truy vấn ngoài cùng vì nó dư thừa hoặc đơn giản là chuyển qua các kết quả từ bảng bên trong.

Có ai nghĩ rằng điều này có thể không phải là trường hợp?

Hầu hết các cơ sở dữ liệu khá rõ ràng về thực tế rằng ORDER BYmột truy vấn con là:

• Không được phép: Ví dụ: SQL Server, Sybase SQL ở mọi nơi (trừ khi được bổ sung TOPhoặc OFFSET .. FETCH)
• Vô nghĩa: Ví dụ PostgreSQL, DB2 (một lần nữa, trừ khi được bổ sung OFFSET .. FETCHhoặc LIMIT)

Đây là một ví dụ từ hướng dẫn LUW của DB2 (nhấn mạnh của tôi)

Mệnh đề ORDER BY trong phần phụ không ảnh hưởng đến thứ tự của các hàng được trả về bởi một truy vấn. Mệnh đề ORDER BY chỉ ảnh hưởng đến thứ tự của các hàng được trả về nếu nó được chỉ định trong fullselect ngoài cùng.

Từ ngữ khá rõ ràng, giống như của PostgreSQL :

Nếu sắp xếp không được chọn, các hàng sẽ được trả về theo thứ tự không xác định. Thứ tự thực tế trong trường hợp đó sẽ phụ thuộc vào các loại kế hoạch quét và tham gia và thứ tự trên đĩa, nhưng không được dựa vào . Một thứ tự đầu ra cụ thể chỉ có thể được đảm bảo nếu bước sắp xếp được chọn rõ ràng.

Từ đặc điểm kỹ thuật này, có thể theo dõi rằng bất kỳ thứ tự nào phát sinh từ ORDER BYmệnh đề trong bảng dẫn xuất chỉ là ngẫu nhiên và có thể trùng khớp với thứ tự dự kiến ​​của bạn (điều này có trong hầu hết các cơ sở dữ liệu trong ví dụ tầm thường của bạn), nhưng sẽ không khôn ngoan khi dựa vào điều này.

Lưu ý bên lề về DB2:

Cụ thể, DB2 có một tính năng ít được biết đến hơnORDER BY ORDER OF <table-designator> , có thể được sử dụng như sau:

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

Trong trường hợp cụ thể này, thứ tự của bảng dẫn xuất có thể được sử dụng lại một cách rõ ràng trong hầu hết CHỌN bên ngoài

Lưu ý bên lề về Oracle:

Trong nhiều năm, Oracle đã thực hiện OFFSETphân trang bằng cách sử dụng phân trang ROWNUM, có thể được tính toán hợp lý chỉ sau khi đặt một bảng dẫn xuất:

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

Có thể dự đoán một cách hợp lý rằng ít nhất là trong sự hiện diện của ROWNUMmột truy vấn, các phiên bản Oracle trong tương lai sẽ không phá vỡ hành vi này để không phá vỡ tất cả các di sản Oracle SQL ngoài kia, vốn chưa được chuyển sang mong muốn hơn nhiều và OFFSET .. FETCHCú pháp chuẩn SQL có thể đọc được :

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

Đúng. Không có một ORDER BYmệnh đề, thứ tự đầu ra không được xác định và trình hoạch định truy vấn cũng nằm trong phạm vi của nó để cho rằng bạn biết và hiểu điều này.

Nó có thể quyết định rằng vì truy vấn bên ngoài không chỉ định một đơn đặt hàng nên nó có thể bỏ thứ tự trong truy vấn bên trong để tránh thao tác sắp xếp, đặc biệt là nếu không có chỉ mục được nhóm hoặc hoàn toàn không có chỉ mục để hỗ trợ đơn hàng. Nếu không, bây giờ nó có thể làm trong các phiên bản trong tương lai.

Không bao giờ dựa vào hành vi không xác định. Nếu bạn cần một thứ tự cụ thể, đưa ra một ORDER BYđiều khoản ở nơi thích hợp.

Đó là vấn đề rất lớn với hành vi không xác định - hoạt động cho bạn, hoạt động với tôi, định dạng lại ổ cứng trong prod;)

Chúng ta có thể lùi lại một bước và nói rằng theo một nghĩa nào đó, bạn đúng - không có lý do trần tục tại sao bất kỳ RDBMS lành mạnh nào sẽ sắp xếp lại các hàng trong lựa chọn bên trong. Nhưng nó không được bảo đảm - có nghĩa là trong tương lai có thể có một lý do và các nhà cung cấp có thể tự do làm điều đó. Có nghĩa là bất kỳ mã nào dựa trên hành vi này đều là sự thay đổi mà nhà cung cấp có thể thực hiện mà họ không có nghĩa vụ phải công khai, vì đó không phải là một thay đổi vi phạm từ API POV.

Có thực sự là thứ tự sẽ không được đảm bảo cho bảng dẫn xuất dự phòng cụ thể này?

Câu trả lời cho tất cả các phiên bản Postgres hiện tại (mà bạn đang thử nghiệm) là: Không - cho truy vấn cụ thể này. Sắp xếp thứ tự được đảm bảo.

Người dùng máy chủ SQL sẽ không thoải mái với điều này vì Microsoft thậm chí không cho phép ORDER BYtrong các truy vấn con. Thứ tự sắp xếp được đảm bảo cho truy vấn đơn giản này trong Postgres. ORDER BYđược áp dụng trong truy vấn con và truy vấn bên ngoài không làm bất cứ điều gì có thể thay đổi thứ tự.

Hướng dẫn thậm chí còn gợi ý nhiều như trong chương Hàm tổng hợp :

Ngoài ra, việc cung cấp các giá trị đầu vào từ một truy vấn con được sắp xếp thường sẽ hoạt động.

Lưu ý điều này chỉ đúng trong khi các mức truy vấn bên ngoài không thêm các thao tác có thể thay đổi thứ tự. Vì vậy, nó chỉ "được bảo đảm" cho trường hợp đơn giản và không được hỗ trợ bởi tiêu chuẩn SQL. Postgres được tự do sắp xếp lại nếu đó là cơ hội cho các hoạt động bổ sung. Trong trường hợp nghi ngờ thêm mộtORDER BY cho bên ngoài SELECT. (Trong trường hợp đó, bên trong ORDER BYsẽ là tiếng ồn dư thừa cho truy vấn đơn giản này.)