SQL Server 2008 or above: 是否有一个明确的标准来判断我是否应该创建索引？
SQL Server 2008 or above: Is there a clear criterion to determine whether I should or should not create an index?
我一直在阅读 "Microsoft SQL Server 2008: A Beginner's Guide" 并看到了关于索引的章节。这本书很好地演示了如何 创建索引，但没有为什么 创建索引。
我在网上也没能找到满意的解释。我找到的所有不同搜索结果都是主题的变体："how to create an index."
我的问题是：是否有明确的标准可以用来确定我是否应该创建索引？到目前为止，我已经读到应该明智地使用索引，并且它可能会为频繁插入、更新和删除的表带来开销问题（这对我的数据库来说是正确的）。
答案是 "it depends -- keep monitoring and adjusting" 还是有明确的标准可以用来确定我是否应该使用索引？
感谢您的任何见解。
没有明确的标准。只有经验法则：
总体规则：如果一个字段在 "decision context" 中使用（例如 where、join、order by 等...，那么它应该是索引。
之后，归结为使用案例。即
很少阅读，经常修改 - 索引可能会受到伤害。保持索引最新的开销可能会超过索引给相对罕见的 "read" 操作带来的任何好处。
经常阅读，很少修改 - 绝对是。索引维护开销仅在 table 被修改时支付。由于您很少修改，读取操作的效率收益将大大超过索引开销成本。
一些 reads/some 更新 - 无法判断 - 您必须对特定案例进行基准测试。具有一个索引的 table 比具有数百个（重叠？）索引的 table 的维护开销要少得多。
我一直在阅读 "Microsoft SQL Server 2008: A Beginner's Guide" 并看到了关于索引的章节。这本书很好地演示了如何 创建索引，但没有为什么 创建索引。
我在网上也没能找到满意的解释。我找到的所有不同搜索结果都是主题的变体："how to create an index."
我的问题是：是否有明确的标准可以用来确定我是否应该创建索引？到目前为止，我已经读到应该明智地使用索引，并且它可能会为频繁插入、更新和删除的表带来开销问题（这对我的数据库来说是正确的）。
答案是 "it depends -- keep monitoring and adjusting" 还是有明确的标准可以用来确定我是否应该使用索引？
感谢您的任何见解。
没有明确的标准。只有经验法则：
总体规则：如果一个字段在 "decision context" 中使用（例如 where、join、order by 等...，那么它应该是索引。
之后，归结为使用案例。即
很少阅读，经常修改 - 索引可能会受到伤害。保持索引最新的开销可能会超过索引给相对罕见的 "read" 操作带来的任何好处。
经常阅读，很少修改 - 绝对是。索引维护开销仅在 table 被修改时支付。由于您很少修改，读取操作的效率收益将大大超过索引开销成本。
一些 reads/some 更新 - 无法判断 - 您必须对特定案例进行基准测试。具有一个索引的 table 比具有数百个（重叠？）索引的 table 的维护开销要少得多。