总是在数据库表上定义聚集索引是个好主意吗？答案

【问题标题】：Is it a good idea to always define a clustered index on a database table?总是在数据库表上定义聚集索引是个好主意吗？
【发布时间】：2011-07-25 13:03:36
【问题描述】：

我目前正在研究一个广泛使用的 .NET CMS 系统的性能问题，并且有一个包含大约 5,000,000 条记录的特定表，这是这些问题的根本原因，仅查询该表的内容需要2 分钟了解我的本地开发环境。

查看表的架构，我注意到只有一个唯一的非聚集索引，没有聚集索引。

表和索引定义如下

CREATE TABLE [dbo].[MyTable](
    [Id] [uniqueidentifier] NOT NULL,
    [ItemId] [uniqueidentifier] NOT NULL,
    [Language] [nvarchar](50) NOT NULL,
    [FieldId] [uniqueidentifier] NOT NULL,
    [Value] [nvarchar](max) NOT NULL,
    [Created] [datetime] NOT NULL,
    [Updated] [datetime] NOT NULL
)


CREATE UNIQUE NONCLUSTERED INDEX [IX_Unique] ON [dbo].[MyTable] 
(
    [ItemId] ASC,
    [Language] ASC,
    [FieldId] ASC
)

是否有人对此表上的索引有任何建议以提高查询性能，特别是，始终在表上定义聚集索引通常是一种好习惯吗？

谢谢

【问题讨论】：

为了建议哪些索引会有所帮助，我们需要知道您是如何访问该表的。你对它执行了哪些查询？
对于任何“正常”数据表 - 是的，我总是推荐一个 good 聚集索引（在一个狭窄、稳定、唯一且最好是不断增加的列上）。这可能不适用于临时表，例如用于临时表的表。批量插入等等 - 但其他任何事情都可以从良好的聚集索引中受益，是的

标签： sql-server performance indexing

【解决方案1】：

我认为你不能说“总是”好或坏。

对于未执行的查询，您有解释计划吗？

如果该查询的 where 子句不使用索引列，那么附加索引可能会有很大帮助。

【讨论】：

【解决方案2】：

我同意 Randy 的观点，这取决于桌子的主要用途。 This 是一篇关于“聚集索引辩论”的精彩文章。

这里要总结的太多了，但总的来说，INSERT 使用聚集索引总是更快，UPDATE通常更快，而SELECT 更多地取决于其他因素，例如具有覆盖非聚集索引。

【讨论】：

【解决方案3】：

聚集索引根据索引键对表进行排序，并按该顺序物理存储它。这就是为什么只能在任何表上定义 1 个聚集索引的原因。建议在唯一值上建立您的聚集索引以获得最佳结果。

如果有多种查询访问您的表（使用不在聚集索引中的列），最好在这些查询过滤的列上设置更多非聚集索引。

查看this msdn link 了解有关聚集索引的详细信息

【讨论】：