sql-server – PK索引中列的顺序是否重要？

我有一些非常大的表具有相同的基本结构.每个都有一个RowNumber(bigint)和DataDate(日期)列.每晚使用sqlBulkImport加载数据,并且不会加载任何“新”数据 – 它是历史记录(sql标准,而不是Enterprise,因此没有分区).

因为每个数据位都需要绑定到其他系统,并且每个RowNumber / DataDate组合都是唯一的,这就是我的主键.

我注意到由于我在SSMS表设计器中定义PK的方式,首先列出RowNumber,然后列出DataDate.

我也注意到我的碎片总是非常高~99％.

现在,因为每个DataDate只出现一次,我希望索引器每天只添加到页面,但我想知道它是否实际上是基于RowNumber首先进行索引,因此必须转移其他所有内容？

Rownumber不是标识列,它是由外部系统生成的int(遗憾的是).它在每个DataDate的开头重置.

示例数据

RowNumber | DataDate | a | b | c..... 
   1      |2013-08-01| x | y | z 
   2      |2013-08-01| x | y | z 
...
   1      |2013-08-02| x | y | z 
   2      |2013-08-02| x | y | z 
...

数据以RowNumber顺序加载,每个加载一个DataDate.

导入过程是bcp – 我已经尝试加载到临时表,然后从那里按顺序选择(ORDER BY RowNumber,DataDate)但仍然出现高碎片.

解决方法

Does the order of columns in a PK index matter?

是的,它确实.

默认情况下,主键约束在sql Server中由唯一的聚簇索引强制实施.聚集索引定义表中行的逻辑顺序.可能会添加许多额外的索引页来表示b树索引的上层,但聚簇索引的最低(叶)级只是数据本身的逻辑顺序.

要明确它,页面上的行不一定以物理方式存储在聚簇索引键顺序中.页面中有一个单独的间接结构,用于存储指向每一行的指针.此结构按聚簇索引键排序.此外,每个页面都有一个指向聚簇索引键顺序中同一级别的上一页和下一页的指针.

使用(RowNumber,DataDate)的聚簇主键,行首先按行编号进行逻辑排序,然后按DataDate进行逻辑排序 – 因此RowNumber = 1的所有行在逻辑上组合在一起,然后行RowNumber = 2,依此类推.

当您添加新数据(RowNumbers从1到n)时,新行逻辑上属于现有页面,因此sql Server可能需要进行大量工作来拆分页面以腾出空间.所有这些活动都会产生许多额外的工作(包括记录更改),但没有任何收获.

拆分页面也开始约50％为空,因此过多的拆分会导致页面密度较低(行数少于每页最佳行数).这不仅是从磁盘读取的坏消息(密度越低=读取的页面越多),低密度页面在缓存时也占用更多的内存空间.

将聚簇索引更改为(DataDate,RowNumber)意味着新数据(可能是比当前存储的更高的DataDates)附加到新页面上的聚簇索引的逻辑端.这将消除分割页面的不必要开销,并导致更快的加载时间.较少碎片化的数据还意味着预读活动(在正在进行的查询需要之前从磁盘读取页面)可以更有效.

如果不出意外,您的查询更有可能搜索DataDate而不是RowNumber. (DataDate,RowNumber)上的聚簇索引支持DataDate(然后是RowNumber)上的索引搜索.现有的安排仅支持对RowNumber的搜索(并且可能只支持在DataDate上).更改主键后,您可能能够在DataDate上删除现有的非聚簇索引.聚簇索引将比它替换的非聚簇索引更宽,因此您应该进行测试以确保性能保持可接受.

使用bcp导入新数据时,如果导入文件中的数据按聚簇索引键(理想情况下(DataDate,RowNumber))排序并指定bcp选项,则可能会获得更高的性能：

-h "ORDER(DataDate,RowNumber),TABLOCK"

为获得最佳数据加载性能,您可以尝试实现最少日志记录的插入.有关更多信息,请参阅：

SQL Server Index Basics
Effective Clustered Indexes
Bulk Inserts Via TSQL
Minimally Logged Inserts

sql-server – PK索引中列的顺序是否重要？

解决方法

相关推荐