sql - 定义索引 : Which Columns, 和性能影响？

Question

我知道如何使用索引(集群和非集群)
但是我什么时候应该在我的表中使用非集群索引。
应该有什么场景，才能让我的列成为非集群索引。
我已经阅读了 msdn 指南，但仍然有点困惑。

我应该只将唯一的列作为 NC 还是应该有任何其他列也作为 NC。

如果我用 NC 索引使我的表过载，那么它也会降低我的性能吗？

我应该在作为外键的列上使用复合非 C 索引吗？

我知道主键应该是 Clustured，唯一键应该是 NC 但外键呢。

Answer 1

聚集索引定义您的 table 的物理结构(在一定程度上) - 例如它定义了数据的排序顺序。想想电话簿，它是由 (LastName,FirstName) “聚集”的——至少在大多数国家是这样。

每个表只能获得一个聚集索引 - 所以明智地选择它!根据Queen of Indexing, Kimberly Tripp的福音，聚类键应该是狭窄的、稳定的(永远不会改变)、唯一的(是的!)并且理想情况下是不断增加的。

它应该是窄的，因为聚簇键将被添加到每个非聚簇索引的每个条目中——毕竟聚簇键是用于最终找到实际数据的值。

它应该是稳定的，因为不断更新大量索引值是一件代价高昂的事情 - 特别是因为集群键也必须在所有非集群索引中更新。

它需要是唯一的，因为再次 - 它最终是用于定位实际数据的值。如果您选择的列不能保证是唯一的，SQL Server 将通过向它添加一个 4 字节的值来“统一”您的集群键 - 这不是一件好事。

理想情况下，集群键应该不断增加，因为这会导致最少的页面和索引碎片，从而最有利于性能。

聚类键的理想候选者是 INT(或 BIGINT)身份 - 它理想地满足所有这些要求。

至于非聚集索引 - 明智地使用和选择它们!我只能给你一个通用规则:作为外键一部分(引用另一个表)的所有列都应该在索引中 - SQL Server 不会(与流行的看法和许多神话相反)将这样的索引放在适当的位置自动 - 从来没有，从来没有。

除此之外——你需要观察你的系统，看看你有什么样的查询——出现在 WHERE 或 SORT 子句中的所有列都是被索引的潜在候选——但太多的索引也不是一件好事。 ..