两个例子是：
这是否正确，还有其他重要的用例吗？
SQL Server是否可以根据使用模式推荐字段进行索引？
答案 0 :(得分：3)
你会知道你的表现是否不够好。
你提到的事情已经是解决方案的一部分。除了这两个，我还要补充：
这有助于在进行JOIN时非常有帮助，并且SQL Server自动完成不（与常见的城市神话相反，SQL Server 从不自动放置任何索引在外键上。）
是的，从SQL Server 2008开始，如果在SQL Server Management Studio中的查询中包含实际执行计划，它可以为您提供一些关于哪些索引可能有用的提示。
但要小心：有了这个，你只需调整一个SQL查询。您可以将其调整到月球和背部，但仍然具有糟糕的性能，因为单个查询通常不是整个故事，并且调整一个查询以执行得非常好可能会对系统的其余部分产生负面影响。
要真正了解要调整的内容以及如何调整它，您需要使用SQL Server分析器跟踪捕获实际的实际使用情况数据，这些数据会在很长一段时间内以及系统的一天中的不同时间进行在使用中，并检查那些。
阅读SQL Server性能分析：
马克
答案 1 :(得分：1)
这些是索引的唯一理由。
由于“使用模式”很难量化 - 而且变化很大 - 因此无法对索引进行全面陈述。
大量更新（或删除）的索引成本高于收益。
与使用它的少数查询相比，很少使用的索引维护成本最高。
它需要主动实验来确定索引的混合是否对于数据库的当前使用模式是最佳的。这意味着查看查询执行计划以查看使用的内容，并查看慢查询以查看可能缺少的内容。
答案 2 :(得分：1)
排序和查询是设计时中几乎所有索引的“必须”。您必须小心处理集群的索引，以免引入插入/更新延迟。
对此公寓来说，您会发现是否需要更多索引来执行系统生产的性能跟踪，并检测是否有更长时间执行的sql命令。
答案 3 :(得分：1)
如果您的查询速度很慢，最好的办法是开始添加索引。对于大多数中小型数据库来说，花时间计算出早期应用的索引并不能很好地利用你的时间。
答案 4 :(得分：1)
应使用较少冗余数据进行最少更新的频繁访问的列作为索引。 如果没有存储问题，那么应该对数据库进行大量索引。
答案 5 :(得分：0)
您应该几乎总是索引外键（主键自动索引，但不是Fks）。 FK通常用于连接，因此应编入索引。