原文标题 ：Explaining SQL Queries for Better Performance

DATA ENGINEERING

解释 SQL 查询以获得更好的性能

窥探数据库查询执行引擎

Background

数据分析师和数据工程师面临的最常见问题之一是非性能查询，通常称为慢查询。这些查询很慢，通常不是因为处理查询的资源短缺，而是因为您编写的查询效率低下，使用的资源远远多于应有的资源。

大多数数据分析师和一些数据工程师对数据库内部结构知之甚少。那么，如何修复和优化慢查询呢？事实证明，您无需成为数据库专家即可修复慢查询。大多数数据库系统为您提供了一种通过公开数据库执行查询的方式来窥探数据库内部工作的方法。这些是查询计划。

查询优化器创建查询计划。优化器会提出替代计划来执行您的查询，以充分利用您的资源。我将在另一篇文章中详细讨论不同类型的优化器。无论您的数据库使用哪种优化器，它都将遵循大多数数据库订阅的执行顺序，如下所示：

优化器将查看预定义的规则、表和列使用统计信息，并找出更好地运行查询的方法。例如，一些高级优化器（在 Spark 3.0 中）也可以在运行时更改查询计划。这种执行查询的自适应方式在分布式系统中最有用，在分布式系统中，您的查询执行可能会受到不同节点在其他时间完成工作的影响。

查询计划的输出

大多数数据库通过让您使用称为 EXPLAIN 的简单 SQL 关键字来公开计划。如果您执行一条 EXPLAIN 语句，您的数据库将制定一个计划并将其打印在您的 GUI 或控制台上。每个数据库都有不同的内部术语来表示查询执行过程中的不同步骤。查询计划通常包括每个步骤的以下内容：

• 估计总成本——检索所有可用记录的成本
• 估计扫描的行数——在此步骤中扫描/检查的行数（这是索引、分区等的来源）
• 检索到的估计行数 – 输出中的行数（步骤的，而不是整个查询）
• Estimated average width of rows — 输出中行的平均宽度（同样，仅针对此步骤）

请记住，成本是一个任意数字。一些数据库将其映射到获取的数据库页数；其他人做事不同。查看计划的想法是将其视为一个整体——包括总成本、获取的行数、扫描的行数等。

修复不良查询

查看查询执行计划，您可以快速确定您的查询是否正在执行以下操作之一（此列表并非详尽无遗）：

• 在错误条件下连接表——当不需要时，您是否有交叉连接或不等式连接。数据库优化器只能分析它在 SQL 查询中看到的内容；它显然无法理解意图。因此，当您使用交叉连接时，数据库会向您指出您是否打算使用交叉连接。
• 缺少或未使用的索引 — 一些数据库在计划中为您提供高级信息，其中计划明确指出您没有使用索引。相反，您必须使用扫描和检索数据的行数来推断其他人的相同信息。
• 备用索引——一些数据库还为您提供可以使用的备用索引。不过，这种情况很少见。大多数情况下，查询优化器可以在选择索引时做出正确的决定，但是对于优化器来说肯定有一些盲点，它无法做出最好的决定。
• 未使用的分区——就像优化器识别未使用的索引一样，它也可以指示您是否没有使用您创建的分区。不使用分区可能会更昂贵，因为数据库必须去每个分区搜索您想要的数据，可能位于一个或几个分区中。
• 具体优化——所有数据库都有不同的内部结构。他们以不同的方式读取、优化和执行查询。可能有一些特定于数据库的优化应用于查询，使其运行得更快。某些数据库（如 MySQL）为您提供了使用 EXTENDED 关键字查看这些优化的选项。这些信息对于更高级的用户肯定会有所帮助。

一旦确定它，您就可以采取必要的步骤来解决问题。

查询计划的风格

大多数数据库都为您提供了一种查看查询执行详细信息（估计的，如果不是实际的）的方法，但是所有数据库的详细信息都不同。因此，选项也是如此。一些数据库允许您查看估计的执行计划，而其他数据库还允许您查看实际的执行计划。如何？通过执行查询并记录优化器的决定。

EXPLAIN 计划也有不同的详细程度和不同的格式。详细程度通常由 EXTENDED 关键字或 VERBOSE 关键字表示。以下是不同数据库的一些示例及其 EXPLAIN 使用规范：

Conclusion

查询执行计划对于了解查询的工作方式和修复查询的性能问题至关重要。 EXPLAIN 通过让您了解执行计划来帮助您实现这两个目标。如何充分利用这些计划取决于您——您是想阅读未格式化的计划，还是想将它们可视化，或者您想将它们存储为 JSON 文档以供以后分析。看看这会把你带到哪里。如果您是数据分析师或数据工程师，那么您肯定需要做一些解释。

如果您觉得我的文章有用，请订阅并查看我在 🌲 Linktree 上的文章。您也可以考虑通过使用我的推荐链接购买中等会员资格来支持我。[0]