如果未使用所有列,是否将使用我的索引?

是否将使用该索引,还是需要一个仅包含a、B、C的单独索引?

寻找 ,这是理想的情况--索引包含引擎直接进入结果集所需的所有信息。我相信这对于数值类型和字符串类型中的相等性测试都是正确的,尽管它可能会以“%”之类的形式出现故障。另一方面,如果你的WHERE只引用了D,那么你很可能会得到一个索引 扫描 ,这意味着SQL引擎必须扫描A、B和C的所有组合,然后在决定是否将该行添加到结果集中之前检查D是否满足您的条件。在一个特别大的表上,当我发现自己必须对列“D”进行大量查询时,我只为D添加了一个额外的索引,并看到大约90%的性能改进。

编辑:我还建议在SQL Management Studio中使用数据库引擎优化顾问。它会告诉您,如果您的表没有为您想要运行的查询建立理想的索引。

这要看情况了!

WHERE A like '%x%'
  and B = 1
  and C = 1
//
WHERE A = 1
  OR B = 1
  OR C = 1
//
WHERE DateAdd(dd, 1, A) = '2008-01-01'
  AND B = 1
  AND C = 1

这些将不依赖于索引,因为索引没有用处。

点击“显示预计执行计划”确认潜在的索引使用情况。

Composite Index (12g文档,但对早期版本有效)

所以在你的情况下,是的。该索引将/可以使用。这可以通过使用解释计划来验证。

如果MSSQLServer不同(我怀疑可能是这样),您将需要一个新的答案。

编辑: 还应该提到它只会

编辑2:

将使用索引,是的。关于哪些索引将生成更优化的查询计划,它是相当聪明的,应该不会有问题。

就像这类事情一样,不要相信我的话——基准测试。创建一个表,用代表性数据填充它,查询它,索引它,然后再次查询它。

索引包含查询中未使用的列这一事实不会阻止使用它。

这并不是说它是绝对的 使用时,可能会出于不同的原因忽略它(可能是因为一个或多个其他索引更有用)。

从简单的equals查找开始(其中A=1,B='Red'和C=287),是的,将(最有可能)使用索引。索引将首先用于帮助优化器“猜测”与选择匹配的行数,然后用于实际访问这些行。

对于David B关于“like”谓词的评论,SQLServer可能仍然使用索引,这取决于您选择的内容。例如,如果选择count(*),则SQLServer可能会扫描索引并计算与where子句匹配的命中数,因为索引较小,需要扫描的IOs也较少。即使您从基表中选择了一些列,它也可能决定这样做,这取决于SQLServer对索引的选择性。

我同意其他提到检查执行计划以验证是否正在使用索引的人的看法。

以下是几篇阅读执行计划的文章,您会发现这些文章很有用:

http://www.sqlservercentral.com/articles/Administering/executionplans/1345/ http://www.codeproject.com/KB/database/sql-tuning-tutorial-1.aspx

我还推荐一篇关于搜索与扫描的好文章: http://blogs.msdn.com/craigfr/archive/2006/06/26/647852.aspx

克雷格·弗里德曼(Craig Freedman)的博客上有很多好文章,这里还有一篇你应该会觉得有用的文章。这篇文章是关于SQL Server用来决定使用哪个索引的一些因素。。。

http://blogs.msdn.com/craigfr/archive/2006/07/13/664902.aspx

当心! 杰夫

因此,在设计索引时可以利用这一点。比如说,我有一个表,其中包含a、B、C作为键值,列Y和Z包含我知道会经常被语句检索到的数据

SELECT Y FROM table WHERE A = alpha and B = beta and C = gamma 

SELECT Z FROM table WHERE A = alpha and B = beta and C = gamma 

因为我要检索的数据已经在索引读取中