超级会员免费看
本文针对Stonedb数据库中遇到的查询错误进行了深入反思，特别是涉及内连接、外连接、派生表、IN子查询和聚合操作的情况。在无法在tianmu层执行时，查询转入JOIN::exec，探讨了JOIN执行的不同场景，以及JOIN::m_select_limit的作用。同时，文章分析了在Query::Compile阶段执行JOIN::optimize(Finish_LOJ_Transform)的原因，讨论了不同优化阶段参数的意义和影响，以及不做JOIN优化可能带来的后果。
摘要:
stonedb-包含内连接外连接派生表in子查询和聚合-查询结果错误-处理后反思
https://stoneatom.yuque.com/staff-ft8n1u/lsztbl/rxlhws22n0f1otxn/edit#AqyB
反思:
一. 转入JOIN::exec执行
- 当tianmu层无法执行时, 转入mysql/sql层的JOIN::exec执行, 那么JOIN::exec的执行究竟是在执行哪些语法树的分支? 还是从头到尾全部执行?
- 有哪些场景, 可以转入JOIN::exec执行?
- 存在派生表的自定义函数
- 存在派生表的自定义变量
- 存在派生表但是其他需要做表达式计算的投影, 具体是哪些？
- 与派生表做连接, 为什么会转入JOIN::exec执行?
- JOIN::m_select_limit 这个成员是用来做什么的? 什么情况下这个值会为0 ?
- 当与派生表做连接时, JOIN::m_select_limit 成员会如何变化?
订阅专栏 解锁全文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
