我发现内存优化表有一些限制,例如:
>没有(最大)大小的字段
>每行最多约1KB
>没有时间戳字段
>没有计算列
>没有UNIQUE约束
这些都有资格作为滋扰,但如果我真的想解决它们以获得性能优势,我可以制定计划.
真正的问题在于你不能运行ALTER TABLE语句,每次你在一个索引的INCLUDE列表中添加一个字段时,你必须经历this rigmarole.此外,您似乎必须将用户关闭到系统之外,才能对实时DB上的MO表进行任何架构更改.
我发现这完全是令人愤慨的,因为我实际上无法相信微软本可以在这个功能上投入如此多的开发资金,并且让维护变得如此不切实际.这使我得出结论,我必须得到错误的结束;我必须误解一些关于内存优化表的东西,这让我相信维护它们比实际上要困难得多.
那么,我误解了什么?你用过MO表吗?是否有某种秘密开关或过程使它们可以实际使用和维护?
解决方法
与内存中的任何其他内容一样,它具有与之相关的成本和收益.主要好处是可以实现的吞吐量.正如您所提到的,其中一个成本是变更管理的开销.这不会使它成为无用的产品,在我看来,它只是减少了它将提供净效益的案例数量.就像现在可以更新列存储索引并且可以过滤索引一样,我毫不怀疑内存中的功能将会在即将发布的版本中得到改进.
sql Server 2016现已普遍推出.正如我想的那样,In-Memory OLTP已经获得了许多增强功能.大多数更改实现了传统表已经享受一段时间的功能.我的猜测是,未来的功能将同时针对内存和传统表发布.时态表是一个例子.此版本中的新功能由In-Memory和disk-based表支持.
原文地址:https://www.jb51.cc/mssql/79934.html
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。