使用定时任务优化SQL查询

使用定时任务优化SQL查询

技术开发 编程 技术框架 技术发展

 

使用定时任务优化SQL查询

在竞争激烈的IT行业中,主要挑战是使产品在市场上可供用户使用,以便他们不选择任何其他选择。产品的开发旨在以出色的性能和最新技术使客户受益。开发的产品及其性能足以使用户充分利用技术。当然,大多数产品/应用程序可能正在处理后端服务和数据库服务器之间的大量数据流。

一个理想且负责任的敬业软件开发团队认为,编写高效的查询以提供更快,更优化的结果为己任。除此之外,我们还必须优化执行缓慢且无法给出更快结果的SQL查询。

SQL Server查询性能调优被视为主要问题,因为数据库管理人员一直在不断努力以实现其托管系统的最高性能和最低资源使用率。

使用SQL执行计划作为任何数据库管理员的首要方法,我们可以调出查询输出调优。这就是该策略如何建议我们进行调整的方式。我们演示了如何通过执行路线图演示在内部完成任务。查询最昂贵的方面是最好的写查询和推荐的索引。

1.在SQL查询中获得高性能的最佳实践

在进入执行计划之前,让我们通过一些最佳实践来编写高级SQL查询。在这里,我们假设您具有如何编写SQL查询的基本知识,并且以下几点是按照最佳实践实现高性能的要点。

  • 仅对必需列执行此查询,这将确保针对必需列触发db查询,并且不会获取任何不必要的列,从而确保更好地满足效率和规范。除非它完全符合目的,否则请勿回复查询。

  • 应该避免子查询。根据需要执行加入或编写的功能。

  • 利用适当的索引(以获得更快的搜索结果)。

  • 经常注意结果中的NULL事件。

  • 通常在SQL语句涉及多个源的情况下使用表别名。它提高了可读性,维护性,并确保收集了正确的色谱柱。

  • 在ORDER BY子句中,不要包括列号。使用此功能的主要目的是为了可用性和可伸缩性,而不仅仅是性能。创建数据库时可能不必担心,但是随着时间的流逝,新列将应用于SELECT语句,或者无论您是否使用了ColumnNumber,原始表都将重新排序。当您使用ColumnNumber时,结果将是不可预测的,并且在ORDERBY方面是错误的。

  • 在列列表中使用INSERT语句很重要。我们建议这样做,以帮助软件开发人员避免对添加到列的NULL值进行表修改。因此,可以容易地确定影响。

  • 对于T-SQL代码,切勿使用双引号。

  • 您不应该对以“ sp_”开头的存储过程使用前缀。这是SQL为我们提供的系统语法。建议遵循一种独特的模式来命名易于区分的书面程序。

2.什么是SQL执行计划?

如所讨论的,执行计划是SQL查询处理器执行的不同操作的图形表示。当您执行任何查询时,查询处理器将生成一个执行计划以及要启动的查询。基本上,它提供了两个主要的执行计划。

估计执行计划

  • 这种类型的计划是在查询执行之前生成的,或者可以说是在编译期间生成的。

  • 这只是查询处理器的估计。

  • 与此不提供任何运行时信息。

实际执行计划

  • 这种类型的计划是在执行查询后生成的,或者可以说是在运行时间之后生成的。

  • 它由查询处理器提供实际信息。

  • 它提供了所有信息,例如执行该查询时涉及的步骤。

3.如何创建一个SQL执行计划?

当您执行任何查询时,会生成一个执行计划,该查询必然包含该查询以及该计划。还有许多其他方式可以执行此计划。就像您可以使用“菜单”按钮,工具栏按钮和快捷键一样。有关更多详细信息,让我们深入了解以下过程。

  • 快捷键:有一个快捷键可用于检查“估计执行”计划。在“查询”窗口中编写查询后,可以按Ctrl + L。

  • 在查询窗口的上下文菜单中,您将找到一个名为“显示估计的执行计划”的菜单。它的工作方式与上述步骤相同。它将显示“估计执行计划”。另外,在“查询”菜单中,有一个选项可用,名为“显示估计的执行计划”。

  • 在工具栏中,有一个带有此图像的按钮。图像这就是“实际执行”计划的确切功能,这里有一个快捷键,即Ctrl +M。

(注意:如果该按钮不存在,请选中“添加或删除按钮”。此外,在“查询”菜单中,有一个名为“包括实际执行计划”的选项。

估计执行计划示例

image.png

实际执行计划示例

image.png

正如您在示例中看到的那样,它显示了实际执行计划。我们已经执行了查询,并且有3个选项卡可用。如果您检查差异,它将显示您花费的扫描时间。我们可以将执行计划分为三个部分。

  • 聚集索引扫描(聚集)

  • 排序操作

  • 选择操作

4. SQL执行计划的组成部分是什么?

由于表中没有可用的数据,它是一个简单的查询,因此估算的执行计划和实际的执行计划将是相同的,但是如果您使用大型查询,则会发现两者之间的差异。您可以使用它来优化查询。

当您将鼠标悬停在“聚集索引扫描”上时,将提供详细的结果。看看下面的截图。

image.png

如果您在上图中看到,SQL提供了不同的详细信息。我们将详细讨论所有内容。

  • 物理操作:物理操作员是执行此类操作的对象。其中一些示例是“索引查找”,“聚簇索引扫描”等。逻辑运算符正在指导此类运算符执行已定义的操作。

  • 逻辑操作:在物理操作中,我们的软件开发人员使用逻辑操作员的工作。它还清楚地说明了必须进行哪些查询以及如何执行查询。

  • 实际执行模式:本节将描述要执行的实际计划。处理引擎使用它,并执行查询。

  • 估计执行模式:与上述计划类似,但唯一的不同是它显示了估计值。

  • 存储:查询触发的输出就像从查询中提取的优化程序一样。

  • 所有执行的合法事实和数字-实际计划将显示执行计划中的所有实际数字和数字。根据这种情况,我们将不会获得任何记录,也不会获得任何回报。

  • 实际批次数:仅在实际执行计划中存在。如果是批处理查询,则将返回“无批处理”。

  • 估计的运营成本:如果查询中涉及其他任何运营成本,则将对此进行计算并显示在此处。

  • 估计的I / O成本:它显示输入和输出成本的准确数量。

  • 估计的CPU成本:它估计使用CPU执行操作的成本。

  • 估计的子树成本:生成执行计划时,它将生成树。从现在开始,您将可以计算

  • 执行次数:仅在实际执行计划中存在。在单个批处理中,优化程序可以处理的执行次数。

  • 估算的执行次数:与上述估算的执行次数相似,但唯一的区别在于它将为您提供估算的值。

  • 每次执行的估计行数:这只是来自Optimizer的估计,即将返回多少行。

  • 预计要读取的行数:这只是来自Optimizer的估计,即将读取多少行。

  • 估计行大小:顾名思义,它向您显示存储的估计行大小。

  • 实际重新绑定-在实际执行计划期间将处于活动状态。它提供了信息,例如必须重新评估对象处理多少次。

  • 倒退实际编号:这部分将在实际执行计划中再次重复。

  • 在关联操作中,通过重复使用内部结果数据集来执行总行数。

  • 已排序:确定执行操作的数据集是否已实现排序。如果您在上面的示例中签入,则会给您False,因为到目前为止尚未进行排序。一旦排序完成,那就是正确的。

  • 节点ID:这是从右到左,然后是通常的从上到下的唯一编号类型。因此,我们可以说,基于执行计划树,右下角将具有NodeID = 1,左上角将具有最大节点数。

在“添加”中,还有另外两个组件。我们可以在下面查看其信息。

  • 对象:定义我们对其执行查询或操作的表。

  • 输出列表:定义选定的列,这些列将显示在数据集或结果中。

在表格中搜索数据

现在,我们将通过一个示例来更深入地研究这个问题,因此在开始之前,让我们梳理一下有关索引以及索引之间的比较的知识。

表格扫描:在这种类型的扫描中,无论其是否符合给定的搜索结果,都以触及表格的每一行的方式全面执行扫描。这种类型的扫描是检查小型表的有效方法,在该表中,大多数行都符合谓词的条件。估计成本将与表中的总行数成比例。

索引扫描:如果表具有聚集索引,则执行的查询应覆盖所有行和列。因此,建议触发一个查询,该查询将覆盖表的大多数行或几乎所有行。即没有WHERE或Getting子句的查询,将使用索引搜索。在数据库优化的过程中,查询优化器从可用索引中选择最佳的索引。并且基于该信息,在扫描整个表时会清楚地定义子句功能。

此子句保留数据库的统计信息。

选择正确的索引的那一刻。下一步是将树结构导航到所有匹配的数据点,并使用SQL查询处理器或引擎提取确切的记录。

全表搜索和索引扫描之间的主要区别之一是,当数据在索引树中排序时,数据库引擎会了解何时达到极限并仍在寻找极限。然后,它可以提交问题,或者在适当时传递到下一个数据集。

寻求索引:成本与表中符合条件的行和页面的数量成正比,而不是与表中的总行数成正比,因为只有符合条件的行和包含这些符合条件的行的页面受搜索这三者的影响,因此最快的一个。

5.执行计划如何提高查询性能?

image.png

根据执行计划中显示的上图,有4个不同的查询,但有一些细微的变化。让我们一一看一下,并尝试了解执行计划可以带来哪些改进。

查询1:从Department WHERE DepartmentName ='HR'中选择DepartmentID,DepartmentName

该表没有定义任何主键,因此没有创建任何聚集索引。这将执行完整的表扫描,这在第一个执行计划中可见。如果表中的记录数为百万,则此查询将花费最长时间。

查询2: SELECT EmployeeID,EmployeeName,DepartmentID,BirthDate FROM Employee WHERE DepartmentID = 3

该查询正在执行索引扫描,这比表扫描快一点,因为它将以通过聚簇索引存储数据的方式将数据排序。如果表中包含大量数据,速度仍然会较慢。

查询3: SELECT * FROM Employee WHERE BirthDate ='1982-08-07'我在BirthDate列上创建了一个非聚集索引,如上图所示。请注意,这些列显示在下图中的包含选项卡中。这意味着,只有在select子句中选择了很多列并且WHERE子句位于Birthdate列上时,才能执行索引查找。

第三个执行计划仍在显示索引扫描。使困惑!请参考最佳做法部分中的第一个要点,以获得高性能。您可以在SELECT子句中编写*,而不是特定的列。这阻止了索引查找功能,并且我们没有收到预期的期望性能。尽管在数据库中创建了非集群。现在,让我们检查最终查询。

image.png

查询4:从员工WHERE BirthDate ='1982-08-07'中选择EmployeeID,EmployeeName,DepartmentID,BirthDate

您会注意到,由于我们遵循了最佳实践,并且已准确创建了非聚集索引,因此该查询已使用了索引查找。

为了确定性能改进,应该了解最佳实践和有关SQL Server的深入知识。执行计划通过其图形表示帮助查找丢失的内容,因此人们可以轻松地找到操作项以提高特定查询的性能。我希望这个例子能对如何找出查询中的改进有所启发。

6.结论

在本文中,我们进行了广泛的研究,并获得了有关执行计划的见解。关于如何生成执行计划,计划的执行计划与实际执行计划之间的差异以及执行计划节点的各个组成部分,一些秘密策略是已知的。我们还了解了执行计划如何帮助查找查询中的改进。该工具对于DBA应对日常挑战以及涉及大数据的问题非常有用,因此您可以再次检查执行计划并在需要时优化查询。

技术开发 编程 技术框架 技术发展