sql-server - SQL Server 索引最佳实践 (SQL Server 2008)

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 9 年前。

Improve this question

我对选择正确的索引有一些疑问，并有一些疑问:

聚集索引

最好的候选人是什么？

通常是主键，但如果在搜索中未使用主键，例如 CustomerNo用于搜索客户，应该将聚集索引放在CustomerNo上？

使用 SchemaBinding 的 View

如果有一个带有索引的 View ，我读到这些索引未被使用，但表上的索引被使用。

毫无意义不是吗？或者我错过了重点？使用“NOExpand”强制从 View 而不是表中读取索引会有所不同吗？

非聚集索引

添加非聚集索引以包含每个可能的列直到达到限制是一个好习惯吗？

非常感谢您抽出时间。我正在阅读海量数据库，速度是必须的

Answer 1

聚集索引是这样的索引:(a) 定义表的存储布局(表数据按聚集键进行物理排序)，(b) 用作“行该表上每个非聚集索引中的“定位器”。

因此，聚集索引应该是

• 窄(4 字节是理想的，8 字节还可以 - 其他都太多了)
• 唯一(如果您不使用唯一聚集索引，SQL Server 将向您的表添加 4 字节唯一符)
• 静态(不应更改)
• 最好它应该不断增加
• 固定为 - 例如不要在聚集索引中使用大型 Varchar(x) 列

在这些要求中，INT IDENTITY 似乎是最合乎逻辑、最明显的选择。不要使用可变长度列，不要使用多列(如果可能的话)，不要使用GUID(这是一个非常糟糕的选择，因为它的大小和随机性)

有关集群键和集群索引的更多背景信息 - 阅读 Kimberly Tripp 发布的所有内容!她是 SQL Server 中的索引女王 - 她非常了解自己的东西!

参见例如这些博客文章:

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

一般来说:不要过度索引!过多的索引通常比没有更糟糕!

对于非聚集索引:我通常会索引外键列 - 这些索引有助于 JOIN 和其他操作并使速度更快。

除此之外:不要在数据库中放置太多索引!必须在表上的每个 CRUD 操作中维护每个索引!这是开销 - 不要过度索引!

包含表的所有列的索引是一个特别糟糕的主意，因为它确实不能用于太多用途 - 但会带来大量管理开销。

运行您的应用，对其进行分析 - 查看哪些操作速度较慢，尝试通过向表中添加一些选择性索引来优化这些操作。