内存 OLTP 的索引

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 ）关注我们，并与我们的编辑和其他读者朋友交流。