索引結構，以最大限度地提高索引列的任意組合速度

Question

我有大約五個可能的索引列，它們都以不同的方式有用的數據庫。我們稱之爲系統，源，熱，時間和行。一起使用系統和行將創建一個唯一的關鍵字，如果按照系統行進行排序，數據庫也將按五個索引變量的任意組合排序（按照我上面列出的順序）。我的問題是，我使用這些列的所有組合：有時我想要加入每個系統行到下一個系統 - （行+ 1），有時我想通過系統源熱量組或地點，有時我想查看系統源的所有條目，其中時間是在特定的窗口等。

基本上，我想要一個索引結構，其功能類似於這五個索引的每個可能的排列（按照正確的順序，當然），而沒有實際做出每一個置換（儘管如果需要，我願意這麼做）。我正在做統計/分析，而不是傳統的數據庫工作，所以索引的大小和創建/更新的速度不是問題;我只關心加快即興查詢的速度，因爲我傾向於認爲它們，運行它們，等待5-10分鐘，然後再也不使用它們。因此我主要關心的是將「等待5-10分鐘」縮短爲「等待1-2分鐘」。

我排序的數據會是這個樣子：

Sys So H Ti R 
1 1 0 .1 1 
1 1 1 .2 2 
1 1 1 .3 3 
1 1 2 .3 4 
1 2 0 .5 5 
1 2 0 .6 6 
1 2 1 .8 7 
1 2 2 .8 8 

編輯：這可以簡化事情有點那個系統幾乎總是需要包括作爲第一列作任何其他4列的排序訂購。

Answer 1

對不起，花了一段時間回到這個，我不得不在其他幾個星期工作。無論如何，在嘗試了一堆東西之後（包括這裏提到的所有東西，即使是蠻力「爲每個置換做一個索引」的方法），我還沒有發現任何可以顯着提高性能的索引方法。然而，我發現了一個替代的非索引解決方案：只選擇我感興趣的行和列到中間表中，然後使用那些而不是完整的表（所以我使用大約5 mil行6列而不是30列35列35列）。最初的選擇和表格創建有點慢，但之後的步驟要快得多，即使我只運行一次（並且考慮多久改變一次，通常會多於一次），我實際上可以節省時間。

我懷疑這種巨大改進的原因對於大多數SQL用戶來說是顯而易見的（可能與頁面文件大小有關），如果是的話，我表示歉意。我唯一的藉口是，我是一名統計學家，試圖自我教導我如何去做這件事，雖然我很體面地得到我想要做的事情（最終），但我對機制的理解如何它的做法令人痛心地接近「這是一個神奇的黑盒子，不用擔心。」

Answer 2

如果你是只有與SELECT速度有關，不關心INSERT，那麼你可以實現所有的組合作爲INDEXED視圖。您只需要24倍於原始表格的存儲空間，製作一個表格和23個INDEXED VIEWs，每列5個列。

例如

create table data (
    id int identity primary key clustered, 
    sys int, 
    so int, 
    h float, 
    ti datetime, 
    r int); 
GO 
create view dbo.data_v1 with schemabinding as 
    select sys, so, h, ti, r 
    from dbo.data; 
GO 
create unique clustered index cix_data_v1 on data_v1(sys, h, ti, r, so) 
GO 
create view dbo.data_v2 with schemabinding as 
    select sys, so, h, ti, r 
    from dbo.data; 
GO 
create unique clustered index cix_data_v2 on data_v2(sys, ti, r, so, h) 
GO 

-- and so on and so forth, keeping "sys" anchored at the front 

不過請注意，
Q. Why isn't my indexed view being picked up by the query optimizer for use in the query plan?（鏈接文章內搜索）

---

如果空間是一個問題，那麼下一個最好的辦法是在每個4列創建單獨的索引，領先與系統，即（sys，ti），（sys，r）等。這些可以一起使用，如果它將幫助查詢，否則它將恢復到全表掃描。