在内存优化表上使用索引

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 上的密钥唯一性，那么您需要在 PK1 和 PK2 上使用非集群密钥。注意PK2不要有很多重复。

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

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

谢谢你

Answer 2

由于大多数搜索将在 PK2 上进行，因此我会按照在目标表中查询的所需顺序从源表中卸载数据。示例：

UNLOAD TO "loadfile" SELECT * FROM sourcetable ORDER BY pk2, pk1;

DROP INDEXES ON targettable;

LOAD FROM "loadfile" INSERT INTO targettable;

CREATE NONCLUSTERED INDEX idxpk2 ON targettable(pk2);

CREATE NONCLUSTERED INDEX idxpk1 ON targettable(pk1);

在目标表中以最常被查询的排序顺序卸载数据与 pk2 上的 CLUSTERING 基本相同，只是您不必对目标表中的数据进行物理重新排序。通过在将新数据加载到目标表之前删除目标表上的索引，加载速度也会有所提高，并且重新创建索引将优化访问。

见我的相关@​​987654321@