内存优化表 - 它们真的很难维护吗？

Question

我正在研究从 MS SQL 2012 升级到 2014 的好处。SQL 2014 的一大卖点是内存优化表，这显然使查询速度超快。

我发现内存优化表有一些限制，例如：

• 没有(max)大小的字段
• 每行最大 ~1KB
• 无timestamp字段
• 没有计算列
• 没有UNIQUE限制

这些都属于麻烦事，但如果我真的想解决这些问题以获得性能优势，我可以制定计划。

真正的问题是您无法运行ALTER TABLE语句，并且每次向索引列表添加字段时都必须经历这些繁琐INCLUDE的过程。此外，您似乎必须将用户拒之门外，才能对实时数据库上的 MO 表进行任何架构更改。

我觉得这简直太离谱了，以至于我实际上无法相信 Microsoft 会在此功能上投入如此多的开发资金，却让其维护起来如此不切实际。这使我得出结论，我一定是拿错了棍子的一端；我一定误解了内存优化表的某些内容，这让我相信维护它们比实际困难得多。

那么，我误解了什么？你用过MO表吗？是否有某种秘密开关或过程使它们易于使用和维护？

Answer 1

不，在内存中确实如此未经打磨。如果你熟悉敏捷，你就会知道“最小可交付产品”的概念；内存就是这样。我觉得 MS 需要对 SAP 的 Hana 及其同类做出回应。这是他们可以在 2014 年发布的时间范围内进行调试的内容。

与内存中的其他任何东西一样，它也有与之相关的成本和收益。主要的好处是可以实现的吞吐量。正如您提到的，成本之一是变更管理的开销。这并没有使它成为无用的产品，在我看来，它只是减少了提供净收益的情况的数量。正如列存储索引现在可以更新并且可以过滤索引一样，我毫不怀疑内存中的功能会在即将发布的版本中得到改进。

SQL Server 2016 现已正式发布。正如我所设想的，内存中 OLTP已经获得了许多增强。大多数更改实现了传统表已经享受了一段时间的功能。我的猜测是，未来的功能将同时针对内存表和传统表发布。时态表就是一个典型的例子。此版本中的新功能受In-Memory和基于磁盘的表支持。

Answer 2

新技术的问题之一——尤其是一个 V1 版本，因为功能不完整而被大声披露——是每个人都加入了潮流，并认为它非常适合每个工作负载。它不是。Hekaton 的最佳选择是 256 GB 以下的 OLTP 工作负载，在 2-4 个套接字上进行大量点查找。这与您的工作量相符吗？

许多限制与内存表与本地编译的过程相结合有关。您当然可以通过使用内存表而不是使用本机编译的过程来绕过其中的一些限制，或者至少不是唯一的。

显然，您需要测试在您的环境中性能提升是否显着，如果是，那么权衡是否值得。如果您从内存中的表中获得了巨大的性能提升，我不确定您为什么要担心将对 INCLUDE 列执行多少维护。根据定义，您的内存索引是覆盖的。这些应该只有助于避免对传统非聚集索引的范围或完整扫描进行查找，并且这些操作实际上不应该发生在内存表中（同样，您应该分析您的工作负载并查看哪些操作改进而哪些没有——这并不都是双赢的）。您今天在索引上使用 INCLUDE 列的频率如何？

基本上，如果它的 V1 形式对您来说不值得，请不要使用它。这不是我们能回答你一个问题，只是告诉你，很多客户都愿意住与局限，以及正在使用的功能来获取巨大利益，尽管他们。

SQL Server 2016

如果您正在迈向 SQL Server 2016，我已经在博客中介绍了您将在内存中 OLTP 中看到的增强功能，以及一些限制的消除。最为显着地：

• 最大持久表大小增加：256 GB => 2 TB
• LOB/MAX 列、可空列上的索引、删除 BIN2 整理要求
• 更改和重新编译程序
• 对 ALTER TABLE 的一些支持 - 它将处于脱机状态，但您应该能够更改和/或删除/重新创建索引（但这似乎不受当前 CTP 版本的支持，因此不要将此作为保证）
• DML 触发器、FK/检查约束、MARS
• OR, NOT, IN, EXISTS, DISTINCT, UNION, OUTER JOINs
• 并行性