将聚集索引添加到现有表会提高性能吗？

Question

我继承了一个 SQL 2005 数据库，其中一个表在大约 15 年的时间里增长到大约 1700 万条记录，现在速度非常慢。

表格布局大概是这样的：

id_column = nvarchar(20),indexed, not unique
column2 = nvarchar(20), indexed, not unique
column3 = nvarchar(10), indexed, not unique
column4 = nvarchar(10), indexed, not unique
column5 = numeric(8,0), indexed, not unique
column6 = numeric(8,0), indexed, not unique
column7 = nvarchar(20), indexed, not unique
column8 = nvarchar(10), indexed, not unique

（还有大约 5 列看起来几乎相同，但未编入索引）

“id”字段是最终用户在前端应用程序中输入的值。

没有定义的主键，也没有可以组合成唯一行的列（除非所有列都组合在一起）。该表实际上是另一个表的“详细信息”表，但没有确保参照完整性的约束。

每一列都在查询中的“where”子句中大量使用，这就是为什么我假设每个列都有一个索引，或者可能是另一个 DBA 拼命尝试加快速度。

说了这么多，我的问题是：在这一点上添加聚集索引对我有什么好处吗？

如果我确实添加了一个聚集索引，我认为它必须是一个新列，即一个标识列？基本上，这值得麻烦吗？

感谢任何建议。

Answer 1

如果有理由需要它，我会说只添加聚簇索引。所以问这些问题；

数据的顺序有意义吗？

插入数据的方式是否有顺序价值？

我是否需要使用要求它具有聚集索引的功能，例如全文索引？

如果对这些问题的回答都是“否”，那么聚集索引可能对良好的非聚集索引策略没有任何额外帮助。相反，您可能需要考虑更新统计信息的方式和时间、刷新索引的时间以及过滤索引在您的情况下是否有意义。以表格为例，很难说，但进一步规范化表格并使用数字键而不是 nvarchar 可能是有意义的。

http://www.mssqltips.com/sqlservertip/3041/when-sql-server-nonclustered-indexes-are-faster-than-clustered-indexes/ 这篇文章很好地说明了非聚集索引何时更有意义。

Answer 2

我建议添加一个聚集索引，即使它是一个标识列，原因有 3 个：

1. 假设您现有的查询每次都必须遍历整个表，clustered index scan is still faster than a table scan。

2. 该表是其他表的子表。通过一些额外的工作，您可以使用新的child_id 来加入父表。这启用了聚集索引查找，在某些情况下它比扫描快得多。

3. 取决于它们的设置方式，现有索引可能效果不佳。我遇到了一些糟糕的索引，每个索引包含 1 列，或者索引不包含适当的列，从而导致代价高昂的 Key Lookups 操作。 Check your index stats 看看它们是否正在被使用。