BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

内存OLTP的索引

| 作者 Jonathan Allen 关注 594 他的粉丝 ,译者 梅雪松 关注 0 他的粉丝 发布于 2014年2月11日. 估计阅读时间: 3 分钟 | AICon 关注机器学习、计算机视觉、NLP、自动驾驶等20+AI热点技术和最新落地成功案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT