加入查询分解

Evg*_*nik 6 performance join optimization query-performance

我有一个关于查询分解和本地化的问题,如下所示:

在此处输入图片说明

加入 3 个表时(这里EMP,ASGPROJ)有什么特定的顺序,什么时候加入哪个表?
为什么ASGEMP首先加入,然后“结果”加入PROJ

是否可以不并行连接所有 3 个表:

在此处输入图片说明

将下面也有可能(只是切换的顺序PROJEMP): 在此处输入图片说明

Tod*_*ett 2

所示问题是将关系演算(SQL 是其变体)转换为关系代数,关系代数由 Codd 在关系上定义的原始运算符组成。我假设 EMP、ASG 和 PROJ 代表员工、项目以及员工到项目的分配。正如关系演算中所述,该查询要求提供非 J. Doe 且被分配到 CAD/CAM 项目持续时间为 12 或 24 个月的员工的姓名。所讨论的运算符(自然连接)是关联的 - 这意味着能够以任何方式对操作数进行分组而不更改结果。因此,EMP、ASG 和 PROG 的加入顺序并不重要。这是因为自然连接实际上只是 EMP、ASG 和 PROG 的乘积,然后受 EMP 而不是 J. Doe、ASG DUR 12 或 24、PROG CAD/CAM、EMP.ENO = ASG.ENO 和 ASG.PNO 的限制= PROJ.PNO,则只有 ENAME 列投影出来。当您以这种方式思考时,您会意识到,要首先获得 EMP、ASG 和 PROJ 中的行的乘积,它们相乘的顺序并没有什么区别。这对应于整数代数,其中 3、6 和 2 的乘法顺序没有区别。以这种方式思考也说明了为什么不能“并行”进行连接。你不能采用 ASG 和 PROJ 的乘积,以及 ASG 和 EMP 的乘积,然后......怎么办?就像你可以取 3 和 6 的乘积,即 18,以及 6 和 2,即 12,然后......什么?得到正确答案 - 36。

这是一个很好的问题,因为它表明优化器在解析关系演算时的工作是首先构建关系代数中等效运算符的相应树。有很多方法可以构建产生相同结果的树,正如 Marco 指出的那样,优化器的工作是找出哪种方法成本最低。该成本估计的一部分是确定哪些访问方法(即索引)可用于执行每个关系运算符以及每个方法的成本。通过这种方式,可以添加和删除访问方法,而不会影响查询的制定。与 SQL DBMS 之前的导航系统相比,这是一个巨大的优势。Fabian Pascal 的《SQL 和关系基础知识》一书对此很有帮助,尽管该书是 20 多年前写的,但它仍然提供了我所发现的对这些概念的最佳解释。不幸的是,它现在已经绝版,但您也许可以购买旧版。不过,您可以在他的网站上购买他的实用数据库基础系列。我还强烈推荐 Chris Date、Hugh Darwen 和/或 David McGoveran 有关该主题的任何著作。