sql-server - 聚集和非聚集索引性能

Question

我有一个巨大的表(约 1000 万行)，在随机的 uniqueidentifier 列上有集群 PK。我对此表执行的最多操作是如果尚不存在具有相同 pk 的行，则插入新行。 (为了提高性能，我使用 IGNORE_DUP_KEY = ON 选项)

我的问题是

我可以完全删除该表上的聚集索引吗？我的意思是，当我将一行插入具有聚集索引的表时，它应该重新排列数据的物理位置。也许最好删除聚集索引并在该列上创建非聚集索引以避免数据重新排列？

我无法在实时数据库上进行实验，因为如果性能下降，那将是一件令人头痛的事情。在测试数据库上，在使用聚集索引的情况下，我只能看到“聚集索引插入 100%”，在使用非聚集索引的情况下，我只能看到“表插入”+非聚集索引中的一些查找操作。

提前致谢

Answer 1

GUID 似乎是主键的自然选择 - 如果您确实必须这样做，您可能会争论将其用作表的主键。我强烈建议不要这样做，即使用 GUID 列作为聚集键，这是 SQL Server 默认执行的操作，除非您明确告诉它不要这样做。 p>

您确实需要分开两个问题:

1) 主键是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这实际上可以是任何东西 - INT、GUID、字符串 - 选择最适合您的场景的内容。

2) 聚集键(定义表上“聚集索引”的一列或多列) - 这是一个物理与存储相关的东西，在这里，小型、稳定、不断增加的数据类型是您的最佳选择 - INT 或 BIGINT 作为默认选项。

默认情况下，SQL Server 表上的主键也用作聚簇键 - 但不必如此!我个人看到，当将之前基于 GUID 的主键/聚集键分解为两个单独的键时，性能得到了巨大的提升 - GUID 上的主(逻辑)键和 GUID 上的聚集(排序)键一个单独的 INT IDENTITY(1,1) 列。

如Kimberly Tripp - 索引女王 - 和其他人已经说过很多次 - GUID 作为集群键并不是最佳的，因为由于它的随机性，它将导致大量页面和索引碎片以及通常较差的性能。

是的，我知道 - SQL Server 2005 及更高版本中有 newsequentialid() - 但即便如此，它也不是真正且完全顺序的，因此也会遇到与 GUID 相同的问题 - 只是有一点点不太明显。

然后还有另一个问题需要考虑:表上的聚集键也将添加到表上每个非聚集索引的每个条目中 - 因此您确实希望确保它尽可能小。通常，具有 2+ 十亿行的 INT 对于绝大多数表来说应该足够了 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存中节省数百兆字节的存储空间。

快速计算 - 使用 INT 与 GUID 作为主键和聚类键:

• 具有 1'000'000 行的基表(3.8 MB 与 15.26 MB)
• 6 个非聚集索引(22.89 MB 与 91.55 MB)

总计:25 MB 与 106 MB - 而且这只是在一个表上!

还有一些值得深思的东西 - Kimberly Tripp 写的很棒的东西 - 读它，再读它，消化它!这确实是 SQL Server 索引的福音。正如她在“聚集索引辩论继续”中所展示的那样，拥有一个良好的聚集键(而不是没有或不好的聚集键)确实可以加快几乎所有数据库操作的速度!这是一个好主意 - 但它必须是一个好的聚类键......

• GUIDs as PRIMARY KEY and/or clustered key
• The clustered index debate continues
• Ever-increasing clustering key - the Clustered Index Debate..........again!
• Disk space is cheap - that's not the point!

马克