我正在计划软件是一个OLAP应用程序（它有助于分析计量数据），并且将为其数据库设置某种星型模式，因为存储的值将从不同的角度进行查看（时间，来源，类型等），请求将要求沿这些维度的汇总数据。查询倾向于提供大量行（最多约10万行）。
我对这个主题的研究（另见my question here）似乎表明位图索引是按照我计划的方式搜索数据的好方法。但是，我想支持多个数据库引擎，其中一些不在其表（特别是MySQL）上提供位图索引。
现在，我当然可以构建和维护自己的位图索引，并使用它来查找指向事实表的行ID。但是，我怀疑这会破坏索引的整个目的，因为数据库仍然会在B-Tree中搜索行ID。有更深刻的理论背景或更多经验的人能否告诉我，我是否仍然可以获得任何东西，比如不必在维度表上进行缓慢的JOIN？
如果答案不是直截了当的话，我也很感谢我要评估的内容。
答案 0 :(得分：2)
当使用自定义数据结构在内存中操作大量数据时，我对位图索引运气不错，但是对于没有良好的第三方数据库实现它们有点尴尬（类似postgresql） ）用于扩展其索引结构的API。
一般情况下，因为如果我的经验可以作为指导，你将无论如何都会搜索B-Tree索引。
所以，没有。
如果您的应用程序本质上是OLAP，并且您有少量维度自然地分组到有序范围中，并且您确实需要更改问题的渐近性，那么您可以考虑构建一个类似于结构的“和表”您可以使用2 ^ d操作查询任何分层答案，如果您正在进行大量相关查询，则可以分摊它。
在坐标为x和y的2d中的示例，其中您感兴趣的是从（x1，y1）到（x2，y2）的范围内的总和。
单独存储，您必须将与区域成比例的多个条目相加。
使用sumtable，对于每个位置（x，y），不存储该位置的值，而是存储从（0,0）到（x，y）的区域的总和。
然后，您可以通过询问：
来回答任何范围查询sum（x2，y2） - sum（x1，y2） - sum（x2，y1）+ sum（x1，y1）
一个恒定的开销量（好吧，数据集大小的对数，假设你有一个关于x和y的索引，并将它存储在SQL中）
如果你有一些复杂的属性没有分解成范围，但可以处理简单的词典索引，日期等，这当然就会失效。
答案 1 :(得分：1)
一些不直接支持位图索引的数据库引擎仍然具有可以执行此类查询而无需访问事实表的星型优化。例如，SQL Server有一个名为Index Intersection的功能，它通过动态构建位图来执行类似的操作来执行解析。 Microsoft 声明，其性能与位图索引相当。请参阅This posting，了解该主题的一些消息。
如果MySQL这样做，我不确定我的头脑，但Postgresql肯定会这样做。 IIRC的一些变体（Greenplum，我认为）也直接支持位图索引，并且有一些关于将它合并到主数据库引擎中的讨论。我不记得这是否已经完成。我认为您会发现大多数现代DBMS平台都提供了这种或那种星型查询优化，因此您可能不需要重新发明轮子。你可能会发现一两个不能做到这一点，但你总是可以选择不支持它们。