内存优化表（Memory Optimized Tables）承诺会带来显著的性能提升，但往往很难使用。使用困难很大一部分来源于不能改变它的表 schema 和索引这一事实。
之前的规避措施是创建一张临时表，把数据复制过来，删除原来的内存优化表，然后创建并且载入新的内存优化表。对以下操作而言没必要再这样做规避了：
- 改变 bucket 总数。bucket 总数太高会浪费内存，太低则损害性能。
- 增加和移动索引。请注意在 ALTER Table 命令之外，无法创建或移动索引。
- 改变、增加和移动列。
- 增加和移动约束。
内存优化表通常受限于绑定本地编译存储过程的 schema。可以用 Schema-bound Dependency 图来查看一个给定的 ALTER 语句是否可行。
请注意 ALTER TABLE 还有一些涉及 workload 的附加限制：
在开始 ALTER TABLE 操作之前，要先暂停 workload。任何在开始 ALTER TABLE 操作之前就启动的用户事务以及对表的访问，都会因序列化验证失败（错误码 41325）而导致 ALTER TABLE 操作失败。
本地编译存储过程
在 2016 版本中本地编译存储过程也可以更改。当新版本的存储过程在进行编译时，将继续使用原来的版本。一旦编译完成，执行挂起请求，数据库切换到新版本上去。
与表一样，以前更改本地存储编译过程要求在创建新的存储过程之前先删除已有的存储过程。在编译窗口期，这会导致执行失败。
注意这个特性不能用来在正常的本地编译存储过程之间进行转换。
查看英文原文： SQL Server 2016: Memory Optimized Tables Made Easier
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群
）。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论