性能比较TWEAK此查询

问题描述：

它需要30秒，载入只有80行。

有什么我们可以做，以减少运行此查询的时间呢？

select 
    CO.ContributorsName [ContributorsName] 
, D.DocumentLastPublished DocumentLastPublished 
, CO.ContributorsImage [AuthorImage] 
, T.NodeAliasPath 
, D.DocumentID 
, BD.* 
from CMS_Tree T 
    inner join Cms_Class CC 
    on T.NodeClassID = CC.ClassID 
    and CC.ClassName = 'wv.blogdata' 
    inner join Cms_Document D 
    on T.NodeID = D.DocumentNodeID 
    inner join WV_BlogData BD 
    on D.DocumentForeignKeyValue = BD.BlogDataID 
    and COALESCE(BD.IsDeleted, 0) = 0 
    inner join WV_Contributors CO 
    on BD.AuthorID = CO.ContributorsID 
where (
    'ALL' = 'ALL' 
    or category = 'All' 
) 
and DocumentCulture = 'en-US'

什么可以谈论列数据类型和索引？ –

执行计划？ – VDK

共80行，共同在所有表中？ – jarlh

答

不要使用*您need.Check您的WHERE子句哪些列还为所有tables.Only指定列名。

这个建议能提高性能多少？这对我来说似乎并不特别有用。 –

这个人在哪里选择*？ –

@DanBracuk'，BD。*从' – SqlZim

答

覆盖索引

（看你的执行计划，看起来你已经有了相应的覆盖索引，但这是很好的一般意见，仍然值得一试）

如果这是一个经常使用的查询，请确保您已在所涉及的表格上获得适当的覆盖索引。请参阅this MSDN页面以了解如何识别潜在的缺失索引。请注意，添加索引会提高查询性能，但会降低插入性能。您还需要确保你有到位的适当的维护计划，以确保您的索引没有得到零散或不平衡。

查询变化

我也建议尝试一些改变您的查询和比较的执行计划。

这是很难做出任何有意义的建议，不看你的数据库，并能够尝试一些事情。

从粗略看看你的查询，我可以看到的最明显的事情是，你正在Cms_Class上执行一个内部连接，但不会从中选择任何数据，或者甚至将它连接到其他表（除了来自CMS_Tree）。我建议删除此连接，并使用存在语句来代替，就像这样：

select 
    CO.ContributorsName [ContributorsName] 
, D.DocumentLastPublished DocumentLastPublished 
, CO.ContributorsImage [AuthorImage] 
, T.NodeAliasPath 
, D.DocumentID 
, BD.* 
from CMS_Tree T 
    inner join Cms_Document D 
    on T.NodeID = D.DocumentNodeID 
    inner join WV_BlogData BD 
    on D.DocumentForeignKeyValue = BD.BlogDataID 
    and COALESCE(BD.IsDeleted, 0) = 0 
    inner join WV_Contributors CO 
    on BD.AuthorID = CO.ContributorsID 
where (
    'ALL' = 'ALL' 
    or category = 'All' 
) 
and DocumentCulture = 'en-US' 
and exists 
(
    select null 
    from Cms_Class CC 
    where T.NodeClassID = CC.ClassID 
    and CC.ClassName = 'wv.blogdata' 
)

试一试，看看执行计划，看看它是否有差别你。

如果你创建新的覆盖索引，重新运行查询，并在执行计划再看看，因为缺少指标的最有效的查询可能不是最有效的查询，一旦你添加索引。

文件缓存（SQL并不总是访问数据的最佳解决方案）

假设你已经做了这两个和查询性能仍然是太可怜了，你可能要问自己，如果你真的需要查询实时数据。查看您的查询，看起来您正在查询来自CMS的数据。只有内容作者实际进行更改时，CMS中的数据才会发生变化。大多数情况下，数据将从请求到请求保持不变。这意味着，从SQL要访问的内容，每次做直接查询可能是矫枉过正满足您的需要。

一个很好的用例例子是看一把umbraco CMS如何访问其数据。它在给定的站点上保存所有发布文档的XML文档缓存。当内容作者发布更改时，它会更新XML文档缓存。

访问缓存比直接与SQL直接交流要高效多了，他们甚至警告用户不要使用他们的SQL API来提供CMS内容，因为它太慢了。

性能比较TWEAK此查询

相关推荐