我正在計劃一個軟件，它的核心是一個OLAP應用程序（它有助於分析計量數據），並將爲其數據庫提供某種星型模式，因爲存儲的值將從不同的角度（時間，源，類型等），並且請求將要求這些維度的彙總數據。查詢往往會提供很多行（高達約100 000）。「假」位圖索引有意義嗎？
我對此主題的研究（另請參閱my question here）似乎表明，位圖索引是以我計劃的方式搜索數據的好方法。但是，我想支持多個數據庫引擎，其中一些不在其表上提供位圖索引（特別是MySQL）。
現在，我當然可以構建和維護我自己的位圖索引，並使用它來查找指向事實表的行ID。但是，我懷疑這會破壞索引的整個目的，因爲數據庫仍然要在B-Tree中搜索行標識符。能否有更深刻的理論背景或更豐富經驗的人告訴我，我是否還能獲得任何東西，比如不必在維度表上做緩慢的JOIN？
如果答案不簡單，我也會很欣賞我必須評估的提示。
某些不直接支持位圖索引的數據庫引擎仍然具有明星優化功能，可以在不觸碰事實表的情況下執行此類查詢。例如，SQL Server具有一個名爲Index Intersection的功能，通過構建位圖來執行相應的操作，從而實現類似的功能。微軟聲稱，這表現與位圖索引相當。請參閱This posting以瞭解關於此主題的一些信息。
如果MySQL做到這一點，我不確定我的頭頂是否定，但Postgresql當然會。 IIRC的一些變體（Greenplum，我認爲）也直接支持位圖索引，並且有人將它引入主DB引擎。我不記得這是否已經完成。
我想你會發現大多數現代DBMS平臺都提供了一種或另一種星型查詢優化，所以你可能不需要重新發明輪子。你可能會發現一兩個不能做到這一點，但你總是可以選擇不支持它們。
在使用自定義數據結構處理大量內存中的數據時，我已經使用位圖索引獲得了好運，但它們在通過第三方數據庫實現時效果不好（postgresql-像）用於擴展其索引結構的API。
一般而言，因爲您將通過B-Tree索引進行搜索，無論如何，如果我的經驗是任何指南，您都不會獲得任何收益。
所以，沒有。
如果您的應用程序本質上是OLAP，並且您有少量維度自然地分組到有序範圍內，並且您確實需要更改問題的漸近性，那麼可以考慮構建一個「結合表」那麼你可以用2^d操作查詢它的任何層次結構答案，如果你正在做一些相關的查詢，你可以分攤它。
2d中的座標爲x和y的示例，您對（x1，y1）至（x2，y2）範圍內的和感興趣。
單獨存儲，您必須總結與該區域成比例的條目數量。
使用sumtable，對於每個位置（x，y）的不存儲位置的值，而是存儲該總和從（0,0）到（x，y）處的區域中。 - 和（X1，Y2） - 和（X2，Y1）+ SUM（X1，Y1）
一個
總和（x2，y2）：
然後，你可以通過詢問回答任何範圍查詢（假設你有一個在x和y上的索引，並且將它存儲在SQL中）的恆定數量的開銷（好吧，對數的數據集大小）
這當然會打破，如果你有複雜的屬性，不分解成範圍內，但可以處理簡單的辭書指標，日期等
對於做suppo數據庫rt位圖索引，我建議使用它們而不是用所有數據庫的最小公分母。 – 2008-11-07 22:44:39