Mnesia：read、match_object、select 和 qlc 查询的时间和空间效率

Question

Mnesia 有四种读取数据库的方法：read, match_object, select, qlc。当然，除了他们肮脏的同行。它们中的每一个都比以前的更具表现力。

1. 其中哪些使用索引？
2. 鉴于此方法之一中的查询，在更具表现力的方法中的相同查询是否会因时间/内存使用而降低效率？多少？

更新。 正如我提到的CRAP ANSWERS，read只是一个键值查找，但经过一段时间的探索，我发现还有函数index_readand index_write，它们以相同的方式工作，但使用索引而不是主键。

Answer 1

一次一个，但从记忆中：

• read始终在keypos. 它基本上是键值查找。
• match_objectselect如果可以的话，将优化查询keypos。也就是说，它仅使用该密钥进行优化。它从不使用其他索引类型。
• qlc有一个查询编译器，如果可能，将尝试使用其他索引，但这完全取决于查询计划器以及它是否触发。erl -man qlc有详细信息，您可以要求它输出其计划。

Mnesia 表基本上是从术语到术语的键值映射。通常，这意味着如果关键部分是查询可以锁定和使用的东西，那么它就会被使用。否则，您将查看全表扫描。这可能很昂贵，但请注意扫描是在内存中进行的，因此通常相当快。

另外，请注意表类型：set是一个哈希表，不能使用部分键匹配。ordered_set是一棵树，可以进行部分匹配：

示例-如果我们有一个键{Id, Timestamp}，查询上{Id, '_'}的关键是相当快上ordered_set，因为词典顺序的手段，我们可以利用树的快速步行。这相当于在传统 RDBMS 中指定复合 INDEX/PRIMARY KEY。

如果您可以安排数据，以便无需附加索引就可以进行简单查询，那么这种表示是首选。还要注意，额外的索引是作为包实现的，所以如果一个索引有很多匹配项，那么效率很低。换句话说，您可能不应该对元组中几乎没有不同值的位置进行索引。最好对具有许多不同（主要是）不同值的事物建立索引，例如用户列的电子邮件地址。