遞歸查詢速度慢嗎？

我的經理問我不要使用遞歸查詢，因爲默認情況下遞歸意味着他聲稱緩慢。遞歸查詢速度慢嗎？

我只是想知道如果遞歸查詢慢，如果有任何其他的替代方式。

編輯：我在談論一般的遞歸查詢。我的經理剛告訴我停止使用遞歸。他的說法是在C＃遞歸函數中很慢。因此，不要在Oracle上使用遞歸查詢，這可能會很慢。

2011-12-12 n3xus

向我們展示您想要實現的目標以及您目前的工作方式，並且我們可能有機會提出其他方法。 –

查詢中有多少行？你的查詢索引？你執行這個查詢多少次？我認爲這個問題有點模糊。 – danihp

我一般在說話。遞歸查詢一般較慢，應該避免？ – n3xus

在績效方面，只有基準很重要。猜測和類比是毫無價值的。

遞歸查詢應該執行得很差，沒有絕對的理由，只是因爲它們是遞歸的。通常發生的情況是，對於較大的數據集，遞歸查詢比針對類似大小的表的非遞歸查詢要昂貴。

這不是一個從不使用遞歸查詢的參數：它是一個用於測試我們的CONNECT BY查詢與代表性數據卷並查看是否可能存在性能問題的參數。用於避免遞歸查詢的機制（例如維護表來存儲展平的層次結構）具有其自己的成本概要。

如果您想了解更多關於遞歸查詢的替代方法，我回答了相關問題。 Check it out.。

2011-12-12 11:03:59 APC

+1 *知情*猜測在優化查詢時有時可能很有價值，但對一些甚至不是RDBMS的錯誤類比是PHB行爲在其最尖端。 –

遞歸一般不一定要慢。

我會考慮一個簡單的事實，即有人說出這樣一個普遍的僞事實，作爲證明他在這個問題上應該被忽略的證據。

如果您編寫遞歸代碼，您對實際執行的內容知之甚少。在源代碼和實際執行的內容之間可能會發生很多事情。

這就是說：有很多情況下，遞歸很慢，或消耗大量內存或導致一個計算器。

但通常遞歸是最明顯的最簡單的解決方案。

所以，如果你遇到一個問題，你認爲：我可以解決這個問題，使用遞歸。做到這一點。

然後測試性能和可伸縮性是否合適。如果它們不是，則可以在調整解決方案（可能通過刪除遞歸）時使用遞歸實現作爲test oracle。

2011-12-12 11:05:11