内存 OLTP 的索引

  • Jonathan Allen
  • 梅雪松

2014 年 2 月 10 日

话题:语言 & 开发

SQL Server 内存 OLTP 的索引与普通索引不一样。这不一定是坏事,只是你要小心它们的差异,避免造成性能问题。

内存优化的非聚簇索引与基于磁盘的非聚簇索引的不同之处在于,他们一直在涵盖。你不需要指定要包含哪些列,除了真正的索引列,“其它列也都将虚拟地涵盖在内”。

非聚簇索引的一个有趣的限制是它只能单向扫描。比如索引是“OrderDate ASC”时,你不能用这个索引以订单日期降序来检索记录。

另一种类型的索引是内存优化的哈希索引。这种索引是为“点式查找操作(point-lookup operations)”和全扫描设计的。它不能用于排序的扫描和不等式查找操作。微软提供了一些在非聚簇索引和哈希索引之间进行选择的指导原则

  • 如果你只需要执行点式查找,也就是说你只需要获取单独索引键值的记录,则应使用哈希索引。
  • 如果你需要获取一定范围内的记录,或者需要按特定顺序排序的记录,则应使用非聚簇索引。
  • 如果你两个都需要,特别是点式查找比较频繁时,可以考虑建立两个索引。你可以在同一索引键上同时创建哈希索引和非聚簇索引。

哈希索引还需要使用桶计数。桶计数的值应该在 N 到 2N 之间,其中 N 是预期的记录数。在操作层面上,0.2N 到 5N 之间都是“可用”的。桶计数在内部始终会被向上取整到 2 的下一次方。

桶计数过高会浪费内存。对于要完全适合 RAM 的内存优化表而言,这是个敏感问题。而桶计数过低则可能会导致其他问题出现:

如果桶计数显著(十倍)低于唯一索引键的数量,很多桶将有多个索引键。这将导致大多数 DML 操作性能下降,特别是点式查找操作(查找单独的索引键)。比如说,即便索引键字段在 WHERE 子句中,并且使用等号进行 SELECT、UPDATE 和 DELETE 操作,性能也会非常差。

哈希索引可能还会遇到重复值的问题。如果多条记录的索引字段的值相同,那么这些记录会产生哈希冲突。如果这种情况很多,例如每个不同的值重复超过 10 次,那么性能就会受到影响。

对于哈希索引,SQL Server 团队建议将其转换成非聚簇索引。

绝大多数情况下应该使用非聚簇索引,因为如果出现重复,非聚簇索引的性能通常更好。如果采用这个选项,你可以考虑唯一化索引键。如下所述:

对于有大量重复的非聚簇索引,应考虑增加索引列。比如将主键字段加到索引键中,确保索引唯一,也就是说,唯一化索引。

如果值确实不同,并且你仍想使用哈希索引,那么你可以使用“超大索引”, 也就是将桶计数值设置为“唯一索引值数量的 20 到 100 倍之间”,从而减少哈希冲突的可能。

原文英文链接:More on Indexes in In-Memory OLTP


感谢吴海星对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

语言 & 开发