2023-06-02 stonedb-修改包含内连接的嵌套外连接-问题反思

文章探讨了在列存储引擎中,包含内连接的嵌套外连接执行缓慢的问题。主要原因是内连接生成的中间结果过大,导致时间复杂度增加。提出了两种优化思路:1) 结合集合论与包的理论分解查询;2) 不上推内连接条件,直接物化结果。实施优化时遇到了表关系识别、预处理阶段的错误等挑战,揭示了对数据库连接处理深入理解的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

摘要:

最近在搞一个列存储引擎的包含内连接的嵌套外连接过慢的问题, 连接执行过慢的原因分析见此前的博客分析, 虽然逻辑很绕, 但是也不是无法分析.

更麻烦的问题在于修改查询计划, 让其能按照代价更小的方式正确的执行.

遇到的问题比我在修改查询计划前设想的更为棘手, 本文做下记录.

包含内连接的嵌套外连接执行过慢的问题原因分析:

  1. 最关键的问题出在内连接生成的中间结果的大小上
  2. 在mysql/sql层, 将内连接的条件全部上推, 导致内连接没有过滤条件,结果就是内连接的结果是R与S的叉乘
  3. 外连接U与(R和S的叉乘)做运算, 现在条件全部集中在外连接这一层, 连接的时间复杂度达到了惊人的 U 连接 (R叉乘S)
  4. 外连接的执行策略为散列连接, 对U做构建散列, 使用R叉乘S的结果集做探测集
  5. 虽然在逻辑理解上可以认为是对U做构建散列,但是这里的散列是一种连续地址的空间, 每次查找元素, 时间复杂度并不是槽位映射的O(1), 而是要从头遍历整个连续地址空间的O(n)
  6. 所以整个的包含内连接的嵌套外连接的执行时间复杂度可以这么理解
    1. 对外表U构建散列, 耗时为 M(U)
    2. 使用R叉乘S的结果集做探测集, 设散列探测单个元素的时间复杂度为O(1), 这里先忽略线性地址空间的O(n)的复杂度导致的问题复杂性的升级, 那么探测过程的耗时可以理解为 N(R*S)
    3. 总的耗时可以理解为 M(U) + N(R*S)
  7. 在执行的过程中, 最大的问题便是R*
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

悟世者

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值