我一直在解决我的工作应用程序中一些糟糕的SQL调用的问题。我一直在研究指数、调整和基准测试。以下是我收集到的一些规则(如果听起来正确请告诉我):
-
对于大量使用的查询，将查询简化为只需要的查询，并重新编写
where语句以首先使用最常用的列。然后在where语句中使用的列上创建一个非聚集索引，并在任何剩余的select列上执行include(当然不包括像nvarchar(max)这样的大列)。 -
如果查询将返回> 20%的表项内容，那么最好进行表扫描，而不要使用索引
-
索引的顺序很重要。你必须确保where语句的结构就像建立索引一样。
现在有一件事我有麻烦找到信息是什么，如果查询是选择列，不属于任何索引的一部分，但使用where语句是?是否使用了索引，叶子节点是否访问表并查找关联的行?
例:表
Id col1 col2 col3
CREATE INDEX my_index
ON my_table (col1)
SELECT Id, col1, col2, col3
FROM my_table
WHERE col1 >= 3 AND col1 <= 6
这里是否使用my_index ?如果是，它如何解析Id, col2, col3?它是否指向表行并拾取值?
回答您的问题，是的，使用my_index。是的，你的索引会指向表的行并选择id, col2和col3的值。这就是索引的作用。
关于你的"规则"
-
规则1有意义。除了我通常不会在索引中"包含"其他列的事实。如上所述，索引将指向表并快速检索所需的行。
-
规则2，我真的不明白。创建索引后，SQL Server将决定使用或不使用哪些索引。你真的不用担心。
-
规则3，顺序并没有什么区别
From dba.stackexchange.com:
有几个概念和术语是很重要的理解在处理索引时。搜索，扫描和查找是一些通过选择语句使用索引的方式。键列的选择性是决定一个函数的有效性的必要条件
当SQL Server查询优化器确定查找所请求数据的最佳方法是扫描范围在索引内。查找通常发生在查询"覆盖"时。通过一个索引，这意味着seek谓词在索引键和显示的列要么在键中，要么包含在键中。扫描发生了当SQL Server查询优化器确定的最佳方式查找数据就是扫描整个索引，然后对结果进行过滤。查找通常发生在索引不包含所有请求时列，无论是在索引键中还是在包含的列中。查询然后，优化器将使用群集键(针对群集键)索引)或RID(针对堆)到"查找";另一个要求列。
通常，seek操作比扫描更有效，因为物理查询较小的数据集。有些情况下这不是事实，比如一个很小的初始数据集，但是这超出了你的问题范围。
现在，您问如何确定索引的有效性有几件事要记住。聚集索引的关键列是称为集群键。这就是唱片在聚集索引的上下文。所有非聚集索引将包括默认情况下集群键，以便在执行查找时必要的。所有索引都将被插入、更新或删除为每个相应的DML语句。话虽如此，确实如此最好在选择语句中的性能增益与插入、删除和更新语句的性能下降
为了确定索引的有效性，您必须确定索引键的选择性。选择性可以定义为a不同记录占总记录的百分比。如果我有一个[人]有100条记录的表，[first_name]列包含90条记录不同的值，我们可以说[first_name]列是90%有选择性的。选择性越高，索引效率越高关键。记住选择性，最好是把你的大部分选择索引键中的第一个列。用我前面的[person]例如，如果我们有一个95%选择性的[last_name]列会怎样?我们希望以[last_name]， [first_name]作为索引索引键。
我知道这是一个有点冗长的回答，但确实有很多这些因素决定了指数的有效性你必须权衡很多事情来提高性能。