向 SQL Server 表添加额外（优化）索引答案

【问题标题】：Adding Extra (refined) indexes to SQL Server table向 SQL Server 表添加额外（优化）索引
【发布时间】：2012-05-14 11:39:03
【问题描述】：

我仍在学习索引的细节，这是我看不到需要的东西。希望社区可以为我指明正确的方向。

该表有 6 个以上的字段。

Field1 是唯一标识符，是 PK。字段 2 和 3 也是唯一标识符。其余的是 varchar/ints，据我所知，它们无关紧要。

三个索引已被放置在表上：集群PK Field2 上的非聚集非唯一 Field2 和 Field3 上的非聚集非唯一

任何索引上都没有包含的列。

我的问题是，是否有任何理由在 field2 上使用单个索引？我的理解是，如果有两列或一列，索引的查找应该没有区别？

【问题讨论】：

【解决方案1】：

你是对的。考虑到 Field2 和 Field3 上的索引的存在以及包含的列相同（即没有）的事实，我认为 Field2 上的索引有用的原因很少：

Sturgeon's law 表明它可能没有做任何有用的事情，但墨菲定律表明删除它会破坏某些东西。

【讨论】：

【解决方案2】：

定义索引时增加的列数（数据），意味着索引大小会按比例增加。所以建议在小/整数字段上创建主键（索引）。

例如假设您在三列上搜索表格

州、县、邮编。

您有时只按州搜索。您有时会按州和县进行搜索。您经常按州、县、邮编搜索。然后是州、县、邮编的索引。将用于所有这三个搜索。

如果您经常单独通过 zip 进行搜索，那么上述索引将不会被使用（无论如何，SQL Server 都不会使用），因为 zip 是该索引的第三部分，查询优化器不会认为该索引有帮助。

然后，您可以单独在 Zip 上创建一个索引，该索引将在此实例中使用。

我猜你正在寻找的答案是它取决于你经常使用的查询的 where 子句以及你的 group by。

【讨论】：

感谢您的回答，但是问题是关于其他 2 个索引的，我们需要使用 uniqueidentifers 的其他原因，我不会讨论。
现在看看修改后的帖子，你会发现你的答案有不同的索引。在您的情况下，您在 Field2 + Field3 上有索引，因此不建议在 Field2 上有索引。如果您确实在 field3 上使用过滤器执行查询，则在 Field3 上创建一个索引。
所以澄清一下，如果仅在 Field3 上进行搜索，则不会使用索引。如果在 Field2 上进行搜索，则规划器应选择最近使用的索引。在 field2 上进行搜索时，使用这两个索引中的任何一个索引的性能应该没有任何差异？
如果硬件有限，field2 的性能可能会有所不同（使用单列和多列索引）。否则你是正确的。

【解决方案3】：

Field1 有一个索引，因为它已被命名为主键并且可能具有默认值 newid()。它必须是独一无二的。

Field2 有索引的原因是因为它是一个外键，很可能会在许多 where 子句和内部连接语句中找到。

不确定为什么 Field3 会收到索引，但如果在任何 where 子句中使用它，最好有它。

索引都是关于快速查找信息的。检查所有 where 子句并确定最适合您个人需求的索引。

【讨论】：

【解决方案4】：

我唯一关心的是如果 Field2 是一个 FK 并且在它所引用的表中进行了删除，优化器是否足够聪明，可以使用以 Field2 作为第一列的复合索引来检查并确保没有任何引用被删除的行。当然，更宽的索引仍然效率较低，因为它每页容纳的行数更少。

唯一的另一件事可能是上升/下降问题，但你没有提到那里的区别。

您可以在删除冗余索引后检查此类操作的执行计划和丢失的索引 DMV。

通常我们总是从 PK、FK 所有索引开始，因此基本的完整性相关操作对于性能来说是可以的；然后添加复合索引以提高读取性能。显然，此时某些 FK 索引最终会变得多余，而您最终会陷入这种情况。

【讨论】：