【发布时间】:2021-10-28 18:18:59
【问题描述】:
问题
因此,我在使用此 SQL 查询时面临的情况是,运行大约需要 12 秒,这使得屏幕超级慢。
目标
进行必要的更改以提高性能并使其更快。我正在考虑使用 UNION 而不是 Where 子句中的 OR?
SELECT Tool.*, Interview.*
FROM Tool
INNER JOIN Interview ON Interview.Id = Tool.InterviewId
WHERE (Tool.ToolTypeId = @ToolTypeId
AND Tool.Is_Active = 1
AND Tool.InterviewId = @InterviewId
AND Tool.ToolId = @ToolId
AND Tool.CustomerId = @CustomerId)
OR Tool.Id = (
SELECT TOP 1 SubTool.Id
FROM Tool SubTool
INNER JOIN Interview subInterview ON subInterview.Id = SubTool.ToolId
WHERE SubTool.ToolTypeId = @ToolTypeId
AND SubTool.Is_Active = 1
AND SubTool.InterviewId != @InterviewId
AND SubTool.ToolId = @ToolId
AND subTool.CustomerId = @CustomerId
AND convert(datetime, subTool.DateTime, 120) < @ToolDateTime
ORDER BY subTool.DateTime DESC, subTool.StartDate DESC,
subTool.EndDate, subTool.Id DESC
)
ORDER BY Tool.StartDate, Tool.Id
注意:我认为在这种情况下,实际的查询输出不是必需的,因为我们正在寻找一些可能会影响性能的结构性问题。
【问题讨论】:
-
为了提高性能,我们需要使用“粘贴计划”查看执行计划。你还说联合可能会改进它,那么当你尝试它时发生了什么?确保它是
union all,而不是union。 -
将尝试访问数据库以便能够检索它,我会尽可能发布它。我只是认为可以确定一些可能影响性能的查询问题,顺便说一下,使用 try_Convert 而不是 convert 也会提高性能,对吧?
-
SQL 不是这样工作的,用于构建查询的语法并不代表 SQL Server 构建的执行计划。它使用包括索引、统计数据等在内的一系列因素来确定如何最好地满足您的要求。因此,了解正在发生的事情的唯一方法是检查执行计划。虽然您使用联合的想法是解决此问题的常见方法,但您只有在尝试时才会知道它是否有帮助。
-
convert(datetime, Tool.DateTime, 120) < @ToolDateTime看起来效率低下,为什么它的列已经不是datetime了?那个子查询也是如此。为了更好地帮助性能,我们需要查看表和索引以及执行计划 -
关于日期时间作为字符串的主题。由于样式 120 是
yyyy-mm-dd hh:mi:ss (24h),因此字符串已经采用了这样的格式,它的排序顺序与转换为DATETIME后的顺序相同。这意味着您可以将参数@ToolDateTime转换为字符串并使用<而无需转换DateTime列,并获得相同的结果。这将是 SARGable 并可能降低一些成本。 (尽管我相信执行计划的这方面可能对整个运行时的贡献很小。)
标签: sql sql-server tsql database-performance