erlang - Mnesia:read、match_object、select和qlc查询的时间和空间效率

Question

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

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

UPD。如I GIVE CRAP ANSWERS提到，read 只是一个键值查找，但经过一段时间的探索，我发现还有函数 index_read 和 index_write，它们在方式相同，但使用索引而不是主键。

Answer 1

一次一个，但凭内存:

• read 总是在 keypos 上使用 Key-lookup。它基本上是键值查找。
• match_object 和 select 将在 keypos 键上优化查询。也就是说，它只使用该键进行优化。它从不使用更多的索引类型。
• qlc 有一个查询编译器，如果可能会尝试使用额外的索引，但这完全取决于查询计划器以及它是否触发。 erl -man qlc 有详细信息，你可以要求它输出它的计划。

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

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

示例 - 如果我们有一个键 {Id, Timestamp}，则查询 {Id, '_'} 作为键 is在 ordered_set 上相当快，因为​​字典顺序意味着我们可以利用树进行快速遍历。这相当于在传统 RDBMS 中指定复合 INDEX/PRIMARY KEY。

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