我有 Log 和 LogItem 表;我正在编写一个查询以从两者中获取一些数据。有数千个,Logs
每个Log
最多可以有 125 个LogItems
有问题的查询很复杂,所以我跳过它(如果有人认为它很重要,我可能会发布它),但是当我运行 SSMS 估计查询计划时,它告诉我一个新的非聚集索引可以将性能提高 100% .
Existing Index: Non-clustered
Key Colums (LogItem): ParentLogID, DateModified, Name, DatabaseModified
Query Plan Recommendation
CREATE NONCLUSTERED INDEX [LogReportIndex]
ON [dbo].[LogItem] ([ParentLogID],[DatabaseModified])
只是为了好玩,我创建了这个新索引并运行了查询,令我惊讶的是,我的查询现在需要大约 1 秒才能运行,而之前是 10 多秒。
我假设我现有的索引将涵盖这个新查询,所以我的问题是为什么在我的新查询中使用的唯一列上创建一个新索引会提高性能?我应该为我的where
子句中使用的每个独特的列组合建立一个索引吗?
注意:我不认为这是因为 SQL Server 正在缓存我的结果,我在创建索引之前运行了大约 25-30 次查询,并且始终花费了 10-15 秒,在索引之后它现在始终是 ~1或更少。
索引中列的顺序很重要。如果过滤需要索引中的第 1 列和第 4 列,则索引将无济于事。它仅在按前 N 个连续列过滤时有用。
这是因为索引是一棵树。您不能有效地选择树的所有节点 where
column3 = something
,因为它们分散在所有其他地方,属于 和 的不同column1
值column2
。但是,如果您知道column1
并且也知道column2
,在树中找到正确的分支是不费吹灰之力的。指数的前沿是最重要的。
只要您的查询被索引的前沿“覆盖”,它就会很有效。数据库索引通常以 B-Tree 的形式实现,并且 B-Tree 的结构规定搜索必须按特定顺序完成,这就是复合索引中字段顺序很重要的原因。
如果您有“漏洞”,例如,如果您在
ParentLogID
and上搜索DatabaseModified
,但只有在 上的索引{ParentLogID, DateModified, Name, DatabaseModified}
,那么只有{ParentLogID}
索引的一部分可以被有效利用。(注意:一些 DBMS 可以
{DatabaseModified}
通过“跳过扫描”使用该部分,但即使您的 DBMS 这样做,它也比常规索引访问效率低得多)。