标签: clustered-index

在设计 SQL 服务器数据架构和后续查询、sproc、视图等时，对于明确部署在 SSD 平台上的数据库设计，集群索引和磁盘上数据顺序的概念是否有意义？

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
“聚集索引决定了表中数据的物理顺序。”

在物理磁盘平台上，考虑它们的设计对我来说很有意义，因为对数据进行物理扫描以检索“顺序”行可能比通过表查找性能更高。
在 SSD 平台上，所有数据读取访问都使用相同的查找。没有“物理顺序”的概念，数据读取不是“顺序”的，因为位存储在同一块硅片上。

那么，在设计应用数据库的过程中，聚集索引的考虑是否与该平台相关？

我最初的想法是，这并不是因为“有序数据”的想法不适用于 SSD 存储和搜索/检索优化。

编辑：我知道 SQL Server会创建一个，我只是在思考在设计/优化期间考虑它是否有意义。

在问了这个比较顺序和非顺序 GUID 的问题后，我尝试比较 INSERT 性能在 1) 一个带有顺序初始化的 GUID 主键newsequentialid()的表，和 2) 一个带有顺序初始化的 INT 主键的表identity(1,1)。我希望后者最快，因为整数的宽度较小，并且生成顺序整数似乎比顺序 GUID 更简单。但令我惊讶的是，带有整数键的表上的 INSERT 比顺序 GUID 表慢得多。

这显示了测试运行的平均时间使用 (ms)：

NEWSEQUENTIALID()  1977
IDENTITY()         2223

谁能解释一下？

使用了以下实验：

SET NOCOUNT ON

CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))

CREATE TABLE TestInt (Id Int NOT NULL identity(1,1) PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))

DECLARE @BatchCounter INT = 1
DECLARE @Numrows INT = 100000


WHILE …

这份 2007 年的白皮书比较了单个 select/insert/delete/update 和 range select 语句在组织为聚集索引的表上的性能与在与 CI 相同的键列上组织为具有非聚集索引的堆的表上的性能桌子。

一般来说，聚集索引选项在测试中表现更好，因为只有一种结构需要维护，而且不需要书签查找。

该论文未涵盖的一个潜在有趣案例是堆上的非聚集索引与聚集索引上的非聚集索引之间的比较。在那种情况下，我曾期望堆甚至可能表现得更好，因为一旦在 NCI 叶级 SQL Server 有一个 RID 可以直接跟随，而不需要遍历聚集索引。

有没有人知道在这个领域进行过类似的正式测试，如果有，结果是什么？

我有几个具有相同基本结构的非常大的桌子。每个都有一个RowNumber (bigint)和DataDate (date)列。每晚都使用 SQLBulkImport 加载数据，并且永远不会加载“新”数据 - 它是历史记录（SQL Standard，不是 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顺序加载， …

我有一个 SQL 语句，该语句将行插入到表中，并且在 TRACKING_NUMBER 列上具有聚集索引。

例如：

INSERT INTO TABL_NAME (TRACKING_NUMBER, COLB, COLC) 
SELECT TRACKING_NUMBER, COL_B, COL_C 
FROM STAGING_TABLE

我的问题是 - 在聚集索引列的 SELECT 语句中使用 ORDER BY 子句是否有帮助，或者是否会因 ORDER BY 子句所需的额外排序而否定任何获得的收益？

我已经使用 ALTER INDEX REBUILD 来删除索引碎片。在某些情况下，REBUILD 似乎并没有消除这种碎片。REBUILD 不去除碎片的原因是什么？似乎这种情况尤其发生在小索引上。

我目前正在将一些数据导入到遗留系统中，并发现该系统不使用单个聚集索引。一个快速的谷歌搜索向我介绍了 HEAP 表的概念，现在我很好奇在什么使用场景中 HEAP 表应该比集群表更受欢迎？

据我了解，HEAP 表仅对审计表和/或插入发生的频率远高于选择的情况有用。它将节省磁盘空间和磁盘 I/O，因为没有要维护的聚集索引，并且由于非常罕见的读取，额外的碎片不会成为问题。

我刚刚建立了一个出版物，我正在尝试更快地应用快照。到目前为止，分发代理遵守MaxBCPThreads设置，但快照代理不遵守。我期望它拆分文件，以便分发代理上的线程会去获取数据。但是在我拍摄快照时似乎无法做到这一点。

我在网上看到的一些可能的解决方案在哪里更新代理配置文件（我最初只是用标志编辑了代理步骤，这适用于 dist 代理但不适用于快照）。

我尝试更新代理配置文件，但没有任何区别。我还发现有人说你应该将 sync_method 设置为native所以我检查了我的脚本，我已经创建了指定native模式的发布。

我想知道是否缺少MaxBCPThreads将所有 bcp 文件拆分为不同文件所需的特定设置。

我以为我已经解决了我自己的问题：看起来您必须有一个具有一组不同范围的聚集索引才能让 SQL Server 将文件拆分为多个分区。但是现在我的索引似乎在所有范围内都是 0。

DBCC SHOW_STATISTICS

经过额外的测试，我发现这似乎只适用于复制表。如果您要基于（索引）视图进行复制，那么您似乎只能获得 1 bcp 文件，而不是从普通表中获得的分区内容。

问题是：为什么 SQL 复制不能像对普通表那样为索引视图分区 bcp 文件？

我正在复制没有表的索引视图本身（“索引视图作为表”）。原因是我必须加入数据库的识别信息供订阅者用于其他事情。到目前为止，我发现的唯一方法是使用 手动拆分我的视图BETWEEN，这不是特别有效。我希望我可以让 SQL Server 在复制普通表时做我期望的事情。

我们的数据库由许多表组成，其中大多数使用整数代理键作为主键。这些主键中约有一半位于标识列上。

数据库开发始于 SQL Server 6.0。

从一开始就遵循的规则之一是，避免根据递增键创建聚集索引，正如您在这些索引优化技巧中找到的那样。

现在使用 SQL Server 2005 和 SQL Server 2008，我强烈的印象是情况发生了变化。同时，这些主键列是表的聚集索引的完美首选。

我一直在阅读有关 SQL Server 内部结构的文章，并且每本书或博客都提到了有关反向扫描的内容。

聚集索引的向后扫描不能使用并行性

唯一说某事的帖子是下面的这个帖子。这篇文章说 SQL Server 团队没有实现反向扫描所需的优化。https://www.itprotoday.com/sql-server/descending-indexes

由于叶级页面是使用双向链表链接的，我不明白为什么向后扫描与向前扫描不同。任何澄清真的很感激。