缓慢的MSSQL存储过程

时间:2017-11-09 21:27:53

标签: sql sql-server tsql stored-procedures

我不确定我缺少什么,但是我有一个存储过程可以将我数据库中的最新内容(通过php)带回来,但它确实很慢。

我有一个带来特定类型数据的视图(大约8000条记录)。

我的存储过程看起来像这样,需要大约9-11秒才能完成,有什么建议吗?善待,我是新手:)

 WITH maxdate As (
    SELECT id_cr, MAX(date_activation) "LastReading"
    FROM [pwf].[dbo].[content_code_service_new_content]
    GROUP BY id_cr
 )
 SELECT DISTINCT TOP 7 s.id_cr, s.date_activation, s.title, s.id_element
 FROM [pwf].[dbo].[content_code_service] s
 INNER JOIN maxdate t on s.id_cr = t.id_cr and s.date_activation = t.LastReading
  WHERE (
       id_service = @id_service
       AND  content_languages_list LIKE '%' + @id_language + '%'
  ) ORDER by date_activation DESC

2 个答案:

答案 0 :(得分:2)

好的,你承认自己有点新手,所以在这之后,你可能想要搜索一下如何调整SQL查询的性能。

但是,这是一个快速的纲要,可以帮助您解决这个特殊问题。

首先:“显示实际执行计划”。 MS SQL中最有用的工具之一是“显示实际执行计划” - 可以在“查询”菜单中找到。选中此选项后,运行查询将在运行查询后在结果和消息旁边创建第三个选项卡。它将显示SQL引擎必须执行的每个操作,以及每个操作所占的百分比。 通常,这足以弄清楚可能出现的问题(如果你的12个步骤中有1个占用95%的时间,那么它可能表明它是如何缓慢地使用数据库的。)

其中最重要的一点是看它是如何从SQL中读取数据的 - 它们是构建它的小树中最右边的节点。有几种可能性:

表扫描。这通常很糟糕 - 这意味着必须阅读整个表才能获得所需内容

聚集索引扫描。这通常也很糟糕。群集索引 表,如果它是扫描,则表示它正在浏览所有记录。

非群集索引扫描。不是最佳,但不一定是问题。它能够使用索引来帮助,但不足以让它可以对它正在寻找的内容执行二进制搜索(它必须扫描整个索引。)

索引搜索(群集或非群集)。这就是您所追求的。它正在执行二进制查找以快速获取其查找的特定数据。

原来如此!你如何获得Index Seeks?您确保您的表在相应的字段上有索引。

通过快速浏览您的查询,以下是SQL必须查找的列:

  • content_code_service_new_content.id_cr
  • content_code_service_new_content.date_activation
  • content_code_service.id_cr
  • content_code_service.date_activation
  • content_code_service.id_service
  • content_code_service.content_languages_list

因此,我会检查这两个表,并确保这些列具有索引。

答案 1 :(得分:1)

我对你的数据一无所知,但我猜这一点会损害你的表现

AND  content_languages_list LIKE '%' + @id_language + '%'

使用这样的通配符搜索总是很慢。有关详细信息,请参阅https://www.brentozar.com/archive/2010/06/sargable-why-string-is-slow/