索引掃描令人費解的性能。爲什麼掃描索引變慢，即使結果集很小並編入索引

我有大表ir_data（150GB），其中包含不同日期的數據（列val_date）。我需要知道在我的應用程序中的各個點上ir_data是否有給定的日期。索引掃描令人費解的性能。爲什麼掃描索引變慢，即使結果集很小並編入索引

select distinct(val_date) from ir_data

我下面的實驗ir_data包含val_date的29個不同的值。

SETUP 1

我預期ir_data（val_date，KEY_ID，other_colum），以幫助快速找到29個值的指數。事實上這需要超過5分鐘：

查詢1的1，行寫着：29，經過時間（秒） - 合計：343.96， SQL查詢：343.958，閱讀效果：0.002

我總是期望索引是一個樹，其中的節點存儲在樹形結構中，例如像這樣

val_date -> key_id -> other_column -> data-nodes 

1.1.2017 -> 0-50  -> A   -> (1.1.2017, 0, Automobile), (1.1.2017, 2, Amsterdam) 
        -> B-E   -> (1.1.2017, 12, Batman) 
     -> 51-100 -> A   -> ... 
         X 
     -> 666-1000 -> A 
        -> B-C 
        -> E 
2.1.2017 -> ...

根據這個結構得到29個不同的val_dates應該很快。

問題：爲什麼需要這麼長時間？

子問題：有沒有辦法解決這個問題而不創建另一個表？

SETUP 2

我創建僅包含val_date另一個索引。這需要大致相同的時間。

查詢的計劃：

The type of query is SELECT. 

2 operator(s) under root 

    |ROOT:EMIT Operator (VA = 2) 
    | 
    | |GROUP SORTED Operator (VA = 1) 
    | |Distinct 
    | | 
    | | |SCAN Operator (VA = 0) 
    | | | FROM TABLE 
    | | | ir_data 
    | | | Index : ir_data_idx1 <-- this is the index containing only val_date. 
    | | | Forward Scan. 
    | | | Positioning at index start. 
    | | | Index contains all needed columns. Base table will not be read. 
    | | | Using I/O Size 16 Kbytes for index leaf pages. 
    | | | With MRU Buffer Replacement Strategy for index leaf pages.

來源

2017-02-22 Beginner

您的查詢是什麼？ –

@OfirWinegarten是的，我應該提到這一點。添加。 – Beginner

你的表是非常大的，以及你的索引。如您在計劃中看到的，引擎執行索引掃描。此操作將會很漫長，因爲它會掃描您的整個索引以獲得不同的值。

作爲第一步，您可以在索引上嘗試update index statistics，不過，我並不認爲這會有所幫助。

如果是一次性手動操作，我想你會滿意5分鐘的操作。

如果這是你的應用程序執行的查詢，那麼你有兩個選擇我能想到的：

正如你在問題中說的 - 通過創建日期附加表正常化的表並使用FK。
創建一個precomputed result set。這是一個物化視圖 - 結果像常規表一樣存儲（與只存儲定義的視圖相反）。
它會自動刷新視圖中的結果並快速檢索值。
重要：比如索引，這將對插入，更新的性能產生影響...
它可以看起來像：
```
create precomputed result set prs_ir_data 
immediate refresh 
as 
select distinct val_date 
from ir_data 
```

你可以閱讀有關預先計算的結果here和here設置爲

來源

2017-02-23 06:19:52

謝謝。你知道他們使用什麼樣的數據結構嗎？我發現很難理解爲什麼需要掃描整個索引來查找搜索結構的頂級屬性。 – Beginner

外鍵思路非常好，我沒有想到。 – Beginner

很高興我能幫到你。我不確定sybases索引的內部結構，但肯定是某種b-tree允許快速搜索和插入 –

A recursive CTE相當快地加速了這個查詢，即在一個大表中很少有不同的值。問題在於，在搜索不同值時搜索索引目前尚未實現。這是一個link to the approach。

來源

2017-03-17 09:33:34 Beginner

索引掃描令人費解的性能。爲什麼掃描索引變慢，即使結果集很小並編入索引

回答

相關問題