GENERATE SERIES比SUBQUERY更快嗎？

-4

我想優化我的查詢，我目前的子查詢裝載SMALLINT值的序列表從0到9999GENERATE SERIES比SUBQUERY更快嗎？

enter image description here

來源

2011-11-27 Frank R.

基準測試和看看。和哪個數據庫？ –

這是我自己的家釀數據庫。 –

也許你不明白數據庫問題。是SQL Server或Oracle或MySQL還是...？如果不理解查詢所寫的數據庫，我們就無法給出性能答案。 –

可以肯定地告訴是唯一的辦法測試它。

幾個月前，我使用PostgreSQL做了類似的測試。問題是用generate_series（）替換日曆表是否有意義。

在我們的案例中，表格速度更快。但是如果你測試了，你可能會發現generate_series（）在一定數量的行上變得更快。（這就是我們發現的，但是行數遠遠超過我們所用的任何東西。）我的猜測是，在那個時候，生成系列所花費的時間比讀取索引和關閉行所需的時間少磁盤。

這是一個猜測，因爲PostgreSQL的EXPLAIN ANALYSE並沒有提供關於磁盤I/O的更多細節。

來源

2011-11-27 23:59:35

我有一個非常類似的情況作爲你的日曆事實表http://stackoverflow.com/questions/2616119/date-lookup-table-1990-01-012041-12-31 ..我的情況是：我有一個事實表只有一個包含從0到9999的小整數（32767）列，並且其索引對在Pick-4抽獎遊戲中已繪製的所有數字（2,820個數字）執行NOT IN子查詢，所以， m認爲使用生成系列比打開一個具有10,000行的額外表更快？ –

我不會假設你的dbms需要「打開一個表」。猜測不能很好地擴展，尤其是對於數據庫管理系統。這就是爲什麼他們都包含一些方法來查看查詢優化器在做什麼。你*應該*假設每個NOT IN查詢將不能使用索引。谷歌的「可推翻的表達」。 10000行不是很多;您的優化器可能會對該表執行順序掃描，即使它*可能使用索引。 –

我們的SET EXPLAIN ON也是另外一個領域，我們沒有很好地解釋發生了什麼。儘管我們的查詢優化器是基於成本的，但是解釋並沒有告訴我們如下事情：磁盤I/O，CPU使用情況，選擇使用表掃描還是索引等。我通常會進行安全引導，以儘量減少其他進程並使用WINDOWS任務管理器性能分析器或UNIX的「sar」（系統活動報告）來查看發生了什麼。我過去的經驗是一個子查詢，它必須通過一個包含10,000行的表格進行掃描，這些行用NOT IN進行評估，相當於OR的成本比做NOT IN（1,2,3 ...）要貴。 –

GENERATE SERIES比SUBQUERY更快嗎？

回答

相關問題