tsql - 在内存优化表上使用索引

Question

尝试制定 SQL Server 2014 内存优化表的方法

一个非常简单的表是应用程序中最活跃的表

• 数据永不改变
• 加载全部通过批量处理
• 大约 2 亿条记录
• 目前所有的读都是用(nolock)

表格

int PK1  
int PK2  
composite clustered PK of PK1, PK2  
non-clustered index on PK2    

PK 是按那个顺序选择的，因为这是加载的顺序

在加载过程中，非聚集索引被禁用，然后在加载结束时重建
该索引会降低加载速度，并且在加载结束时非常分散，无论如何都需要重建

• 所有搜索都是相等的(从不 <, >, <>)
• 大多数搜索都在 PK2 上
• PK1 上的一些简单搜索并用于连接。

终于到了问题。

• 据我了解，内存优化索引不会碎片化。
• 作为内存表，我是否可以反转 PK(PK2，PK1)并在 PK1 上创建第二个索引？
• 没有理由删除并重新创建 PK1 上的索引吗？
• 索引碎片真的会在内存优化表中消失吗？

我认为答案是肯定的，但它似乎是真的。

Guidelines for Using Indexes on Memory-Optimized Tables

进一步检查存在局限性:

• ALTER TABLE、sp_rename、alter bucket_count 以及添加和删除不支持 CREATE TABLE 语句之外的索引内存优化表。
• 不支持 UNIQUE、CHECK 和 FOREIGN KEY 约束。

Transact-SQL Support for In-Memory OLTP
没有提出批评产品的问题，这是一个很酷的功能。但是，如果一个表不支持声明性引用完整性 (DRI)，你能称它为关系数据库吗？

Answer 1

来自您的问题。

It is my understanding that memory-optimized indexes do not fragment.
As an in-memory table would I reverse the PK (PK2, PK1) and have a second index on PK1?
Is there no reason to drop and recreate the index on PK1?
Does index fragmentation truly go away in a memory-optimized table?

问题 1，是的，内存优化索引不会碎片化。

问题2，没有。你想要的是 PK2 上的哈希索引和 PK1 上的哈希索引。如果您想在 PK1 上保留 key 的唯一性，那么您需要在 PK1 和 PK2 上使用非聚集 key 。注意 PK2 没有太多重复。

问题 3，在内存优化表中无法删除和重新创建索引。

问题 4，是的，内存优化表消除了碎片。

谢谢你