删除主键（聚集索引）以提高插入性能

Question

我们遇到SQL超时并已发现瓶颈是审计表 - 我们系统中的所有表都包含导致新审计的插入，更新和删除触发器记录。

这意味着审计表是系统中最大和最繁忙的表。然而，数据只是进来，并且从来没有出现（在这个系统下），所以不需要select性能。

运行select top 10返回最近插入的记录而不是'第一个'记录。当然，order by的作品，但我希望一个选择顶部应该根据他们在光盘上的顺序返回行 - 我期望会返回最低的PK值。

有人建议我们放弃聚集索引，实际上也是主键（唯一约束）。正如我前面提到的，在这个系统中不需要select。

聚簇索引在表上创建什么类型的性能影响？有没有索引，非集群，无密钥表的（非选择）分支是什么？还有其他建议吗？

编辑

我们的审计涉及CLR函数，现在我有没有& PK，索引，FKS等基准来确定的CLR函数&的约束控制下的相对成本。

调查结束后，糟糕的表现与insert声明无关，而是CLR功能，它编排了审计。在删除CLR并改为使用直接TSQL处理程序后，性能提高了20倍。

在测试过程中，我还确定聚集索引和标识列对插入时间没有什么影响，至少相对于发生的任何其他处理而言。

// updating 10k rows in a table with trigger 

// using CLR function 
PK (identity, clustered)- ~78000ms 
No PK, no index - ~81000ms 

// using straight TSQL 
PK (identity, clustered) - 2174ms 
No PK, no index - 2102ms 

Answer 1

根据金佰利特里普 - 索引的女王 - 在桌子上有一个聚集索引实际上有助于INSERT性能：

聚集索引的争论持续

• 镶片在快与堆相比，聚簇表（但仅在“右” 聚簇表中）。此处的主要问题是 ，IAM/PFS中用于确定堆 中的插入位置的查找比群集表（其中插入位置已知， 由群集键定义）中的查找速度慢。插入到定义订单（CL）的 表中并且该订单 不断增加的插入更快。

来源：博客文章叫The Clustered Index Debate Continues....

Answer 2

一个表没有的关键？甚至没有一个自动递增的代理键？ :(

只要关键是单调递增对插入索引维护应该是不错的 - 它只是“在最后补充说：”“集群”只是意味着该表的物理布局遵循指数。 （因为数据是索引的一部分）只要索引没有分段（参见单调增加位），那么集群本身/数据将不会在逻辑上分散，这不应该是性能问题。 （如果有更新，则群集是一个稍微不同的故事：更新的记录可能“增长”并导致碎片）。

我的建议是，如果那是选择的路线，那么... 长凳用实际数据/负载标记，然后决定是否保证这些建议。很高兴看到这种变化是否已经决定，为什么。

快乐编码。

---

此外，当为了任何依赖除此之外，从ORDER BY通过设计存在缺陷。它现在可能会工作，但它是一个实现细节，可能会以微妙的方式进行更改（就像不同的查询计划一样简单）。使用自动递增键时，ORDER BY DESC总是会产生正确的结果（请记住，自动递增ID可以跳过，但除非“重置”，否则它们将总是基于插入顺序增加）。

Answer 3

我的基本理解是即使INSERT操作通常比使用聚簇索引更快。此外，聚簇索引对磁盘空间的要求较低。

一些有趣的测试/场景可能会为您的特殊情况提供一些亮点：http://technet.microsoft.com/en-us/library/cc917672.aspx。

Answer 4

这个scenarion的一个伟大的测试脚本和描述可在蒂博尔Karaszi的博客：SQLblog.com

我的数字并不完全符合他 - 我见更多在批处理语句上的差异比我对每行语句的差异。

由于行数在100万左右，所以我相当一致地在聚集索引上获得单行插入循环，其执行速度比非索引（聚集大约97％，只要非索引）要快。

相反，批处理插入（10000行）更快地进入非索引而非聚集索引（任何集群插入时间的75％-85％）。

clustered - loop  - 1689 
heap  - loop  - 1713 
clustered - one statement - 85 
heap  - one statement - 62 

他介绍什么在每次插入：

堆：的SQL Server需要找到该行应该去。为此，它 使用一个或多个IAM页面作为堆，并且它将这些 交叉引用到数据库文件的一个或多个PFS页面。国际海事组织，应该有 在这里有一个明显的开销的潜力。甚至更多的是，有许多 用户敲击同一张桌子，我可以想象阻止（等待） PFS以及可能还有IAM页面。

Clustered table：现在，这已经很简单了。SQL服务器导航 聚集索引树并查找行应该去的地方。由于这是一个不断增加的索引键，所以每行都会到表 （链表）的末尾。