Bu gereksiz türetilmiş tablo için siparişin garanti edilmemesi GERÇEKTEN mümkün mü?

Lukas Eder ile yaptığı bir Twitter görüşmesinde bu soruyu tökezledim .

Doğru davranış en dış sorguya ORDER BY yan tümcesini uygulamak olsa da, burada, DISTINCT, GROUP BY, JOIN veya en dıştaki sorguda başka bir WHERE yan tümcesi kullanmıyoruz, neden bir RDBMS yalnızca gelen sorgu iç sorgu tarafından sıralanmış olarak?

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

Bu örneği PostgreSQL üzerinde çalıştırdığınızda, hem iç sorgu hem de bu türetilmiş tablo örneği ve aynı sonuç kümesi için aynı Yürütme Planını alırsınız.

Bu nedenle, Planlayıcı'nın en dıştaki sorguyu atacağını varsayarım çünkü gereksizdir veya sadece iç tablodaki sonuçlardan geçer.

Herkes bunun böyle olmadığını düşünüyor mu?

Çoğu veritabanı, ORDER BYbir alt sorgudaki bir ya:

• İzin verilmiyor: Örneğin, SQL Server, Sybase SQL Anywhere ( TOPveya ile tamamlanmadığı sürece OFFSET .. FETCH)
• Anlamsız: Örneğin PostgreSQL, DB2 ( OFFSET .. FETCHveya ile tamamlanmadığı sürece LIMIT)

İşte DB2 LUW kılavuzundan bir örnek (benimkini vurgulayın)

Bir alt seçimdeki ORDER BY deyimi, bir sorgu tarafından döndürülen satırların sırasını etkilemez . ORDER BY deyimi, yalnızca en dıştaki tam seçimlerde belirtilirse döndürülen satırların sırasını etkiler.

İfadeler oldukça açık, tıpkı PostgreSQL'ler gibi :

Sıralama seçilmezse, satırlar belirtilmemiş bir sırada döndürülür. Bu durumda gerçek sıra, tarama ve birleştirme planı türlerine ve diskteki sıraya bağlı olacaktır, ancak buna güvenilmemelidir . Belirli bir çıktı sıralaması yalnızca sıralama adımı açıkça seçildiğinde garanti edilebilir.

Bu spesifikasyondan, ORDER BYtüretilmiş bir tablodaki maddeden kaynaklanan herhangi bir siparişin sadece tesadüfi olduğu ve beklenmedik siparişinizle (önemsiz örneğinizdeki çoğu veritabanında yaptığı) tesadüfen eşleşebileceği takip edilebilir, ancak buna güvenmek akıllıca olmaz bu.

DB2 ile ilgili yan not:

Özellikle, DB2 daha az bilinen bir özelliğe sahiptirORDER BY ORDER OF <table-designator> , bu özellik aşağıdaki gibi kullanılabilir:

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

Bu özel durumda, türetilmiş tablonun sıralaması, çoğu dış SEÇİM'de açıkça yeniden kullanılabilir

Oracle ile ilgili yan not:

Yıllardır Oracle'da , yalnızca türetilmiş bir tablo sipariş ettikten sonra makul bir şekilde hesaplanabilen OFFSETsayfalandırma uygulamak bir uygulama olmuştur :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

En azından ROWNUMbir sorguda, gelecekteki Oracle sürümlerinin, henüz çok daha arzu edilebilir ve okunabilir SQL standart OFFSET .. FETCHsözdizimi:

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

Evet. Bir ORDER BYcümle olmadan çıktı sırası tanımsızdır ve sorgu planlayıcısı bunu bildiğinizi ve anladığınızı varsaymak için kendi amacı dahilindedir.

Dış sorgu bir sipariş belirtmediği için, özellikle sıralamayı destekleyecek bir kümelenmiş dizin veya hiç dizin yoksa bir sıralama işleminden kaçınmak için iç sorgudaki sıralamayı bırakabileceğine karar verebilir. Şimdi değilse , gelecekteki sürümlerde olabilir.

Asla tanımlanmamış davranışlara güvenmeyin. Belirli bir siparişe ihtiyacınız varsa ORDER BY, uygun yerde bir madde verin .

Tanımlanmamış davranışla ilgili en büyük sorun - sizin için çalışıyor, benim için çalışıyor, HDD'yi eşyada yeniden biçimlendiriyor;)

Bir adım geri gidebilir ve bir anlamda haklı olduğunuzu söyleyebiliriz - herhangi bir aklı başında RDBMS'nin iç seçimdeki satırları yeniden düzenlemesinin dünyevi bir nedeni yoktur. Ancak garanti edilmez - yani gelecekte bir sebep olabilir ve satıcılar bunu yapmakta özgürdür. Bu davranışa dayanan herhangi bir kodun, bir satıcının bir API POV'den kopan bir değişiklik olmadığı için, yayınlama yükümlülüğü altında olmayacağı bir değişikliğin merhametinde olduğu anlamına gelir.

Bu gereksiz türetilmiş tablo için siparişin garanti edilmemesi GERÇEKTEN mümkün mü?

Şu anda var olan tüm Postgres (test ettiğiniz) sürümlerinin yanıtı : Hayır - bu sorgu için. Sıralama düzeni garanti edilir.

Microsoft, ORDER BYalt sorgulara bile izin vermediğinden SQL sunucusu çalışanları bundan rahatsız olacaktır . Yine de Postgres'deki bu basit sorgu için sıralama düzeni garanti edilir. ORDER BYalt sorguda uygulanır ve dış sorgu sırasını değiştirebilecek bir şey yapmaz.

Kılavuz, Toplama İşlevleri bölümündeki ipucunu bile işaret ediyor :

Alternatif olarak, sıralı bir alt sorgudan giriş değerlerinin sağlanması genellikle işe yarayacaktır.

Bunun yalnızca dış sorgu düzeyleri sırayı değiştirebilecek işlemler eklemediğinde geçerli olduğunu unutmayın. Bu nedenle, basit durum için yalnızca "garanti edilir" ve bu SQL standardı tarafından desteklenmez. Postgres, ek işlemler için uygunsa yeniden sipariş vermekte serbesttir. Şüphe durumunda ORDER BYdış tarafa bir tane daha ekleyin SELECT. (Bu durumda, ORDER BYbu basit sorgu için iç kısım gereksiz gürültü olacaktır.)