SQL Server 2014 的内存优化表对索引的处理方式与传统表相比差别很大。首先也是最重要的一点，你必须有至少一个索引，但同时索引数不能超过8 个。
必须的那个索引用于组织内存中的数据。不同于传统的表，内存优化表并不支持将数据存储到一个无序堆中。这个索引包含主键，这也是表所唯一允许的唯一列。另外，主键不能是一个标识列。
事实上，标识列是被完全禁止的。这极有可能是支持锁无关写操作所需要的一个限制。
其他7 个索引几乎都是用于辅助join 和order by 操作的。正如前面所提到的，你不能添加额外的唯一索引，也不能使用索引执行外键约束。
你也不能使用触发器解决这些限制，因为内存优化表并不支持。
最后，也不允许检查约束。这意味着几乎所有关注完整性的数据都必须被推送到存储过程或者应用程序层里面。
但是请等一等，还有更多要说明的内容。你还不能在可空的列上放置索引。你也不能使用筛选索引，每一个索引都必须引用每一行。
内部结构
内存优化表中的行并不会被安排在页中。相反，它们分散在内存中。访问它们的唯一方式便是通过索引，这就是至少要有一个索引的原因。
这些索引并不是传统的B 树。它使用一个哈希索引和一个固定数量的桶（buckets）。在理想的情况下，每一个桶仅会容纳一行，因此在创建索引的时候你应该指定期望这个表存储的行的数量。你需要仔细斟酌，对于内存而言超出预算的行数是一个非常大的浪费。
对此，一个计划的替代方案是范围索引（range indexes）。虽然现在还不能用，但是范围索引的期望是能够更好地处理未知数量的行。
明天我们将会继续这个系列，介绍本机编译的查询。
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
Data+AI 下一代数智平台建设
平安业研一体 BizDevOps——降本增效与业务价值最大化实践
基于 Elasticsearch 创建企业 AI 搜索应用实践
评论