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