避免基于递增键创建聚集索引答案

【问题标题】：Avoid creating a clustered index based on an incrementing key避免基于递增键创建聚集索引
【发布时间】：2011-07-15 05:22:42
【问题描述】：

我从mssqlcity.com 得到这个提示。但是，我无法理解它的解释。

避免基于递增键创建聚集索引

例如，如果一个表有代理整数主键声明为 IDENTITY 和聚集索引是在此列上创建，然后每个时间数据被插入到这个表中，行将被添加到末尾桌子。当很多行将是添加了一个“热点”可能会发生。热的当许多查询尝试在同一区域读取或写入数据同时。 “热点”导致 I/O 瓶颈。笔记。默认情况下，SQL 服务器为主键约束。所以，在这个情况下，您应该明确指定 NONCLUSTERED 关键字表示创建一个非聚集索引主键约束。

在阅读之前，我想如果我选择一个本质上是随机的列，这是不正确的，因为这会在添加新行时导致不必要的页面重定位。所以，我认为最好使用排好序的列。

阅读此提示后，我认为它试图说明我们真的不想使用直接排序的列作为我们的聚集索引，因为对于那些写入密集型应用程序来说将会存在 I/O 瓶颈。

我真的不明白他们所说的 I/O 瓶颈的原因。他们是说共享同一页面的太多操作会减慢磁盘操作吗？这是怎么发生的？谁能给我解释一下？

【问题讨论】：

这里提到了“SQL Server 2000 的新功能”，这应该会让你对这篇文章的时代有所了解。
@Quassnoi 是的，我现在得到了 JNK 的提示。我认为该建议适用于 SQL Server 6.5 或更早版本。我用谷歌搜索发现this。这是说一旦将行级锁定功能添加到 SQL Server 7.0。热点问题解决了。
sqlpassion.at/archive/2014/04/15/…

标签： sql sql-server performance indexing

【解决方案1】：

他们所指的热点在 SQL Server 2005 及更高版本中不是问题。

过去发生的事情是，您的所有数据都被写入聚集索引的同一区域和磁盘上的同一扇区，这导致一次创建大量脏页（脏页是数据已更改但未提交到磁盘的页面），并且在运行刷新或检查点时可能会导致问题。

由于 IO 架构的变化（据我了解），较新的版本不会遇到这种行为。

【讨论】：

我明白了，我对热点进行了一些谷歌搜索。你似乎是对的。但是，我仍然不明白为什么写很多脏页会导致性能问题。即使它们不在同一个扇区，我想我们仍然需要将相似数量的数据刷新到磁盘。我会做更多的谷歌搜索。 +1，感谢您的提示。

【解决方案2】：

所有现代事务数据库（过去十年开发的现代手段）都使用事务日志记录。

这意味着对数据库的所有更改都以顺序方式写入一个特殊文件（称为事务日志），然后一个特殊的专用进程解析此文件并将更改应用于实际数据。这称为CHECKPOINT。

如果 10 个线程将 10 条记录插入到具有 IDENTITY 列的表中，引擎将创建 10 条事务日志记录（由名为 Log Writer 的单个进程依次写入），然后，当需要CHECKPOINT，这些记录将被写入相应的数据页（也由单个进程，称为Checkpoint）。

由于它们是连续的，很可能它们将在单个 I/O 操作中写入单个数据页，并且不会发生页面拆分，因为它们之后没有数据。

因此，在不断增加的键上的聚集索引比在随机键上的效率更。

【讨论】：

【解决方案3】：

嗯，我以前听过同样的故事。显然这是一个神话。一般来说，建议倾向于拥有不断增长的集群主键。所有主要的数据库供应商都知道这一点，并减轻了您引用的避免增长密钥的情况。

另见https://dba.stackexchange.com/questions/1584/is-avoid-creating-a-clustered-index-based-on-an-incrementing-key-a-myth-from-sq

引用也违背了建议（来自同一页面）：

考虑创建一个代理整数主键（例如身份）。每个表都必须有一个主键（数据库表中行的唯一标识符）。代理主键是一个具有唯一值但对记录本身没有实际意义的字段，因此用户不应该看到或更改代理主键。一些开发人员使用代理主键，其他开发人员使用数据字段本身作为主键。如果主键包含许多数据字段并且大小很大，请考虑创建代理整数主键。这可以提高查询的性能。

【讨论】：