3

尝试制定 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 上删除并重新创建索引吗？
  • 索引碎片在内存优化表中真的消失了吗？

我认为答案是肯定的，但这似乎很好。

在内存优化表上使用索引的指南

进一步检查存在以下限制：

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

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

4

2 回答 2

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，是的，内存优化表会消除碎片。

谢了，兄弟们

于 2014-05-21T23:22:32.773 回答
0

由于大多数搜索将在 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 基本相同，只是您不必对目标表中的数据进行物理重新排序。通过在将新数据加载到目标表之前删除目标表上的索引，加载速度也会提高，并且重新创建索引将优化访问。

请参阅我的相关问题和答案。

于 2013-08-08T05:42:41.807 回答