摘要:

stonedb-包含内连接外连接派生表in子查询和聚合-查询结果错误-处理后反思

反思:

一. 转入JOIN::exec执行

1. 当tianmu层无法执行时, 转入mysql/sql层的JOIN::exec执行, 那么JOIN::exec的执行究竟是在执行哪些语法树的分支? 还是从头到尾全部执行?
2. 有哪些场景, 可以转入JOIN::exec执行?
   1. 存在派生表的自定义函数
   2. 存在派生表的自定义变量
   3. 存在派生表但是其他需要做表达式计算的投影, 具体是哪些？
3. 与派生表做连接, 为什么会转入JOIN::exec执行? 
4. JOIN::m_select_limit 这个成员是用来做什么的? 什么情况下这个值会为0 ?
5. 当与派生表做连接时, JOIN::m_select_limit 成员会如何变化?

二. 在Query::Compile中执行 JOIN::optimize(OptimizePhase::Finish_LOJ_Transform)

1. 为什么要在构建stonedb的查询序列的时候, 执行最终的join优化? 为什么在此前的步骤中不能做这个事情? 为什么一定要在这做?
2. tianmu层调用的JOIN::optimize, 与mysql/sql层调用的优化处理, 有哪些区别?
3. 在JOIN::optimize中，根据不同的参数控制不同的优化流程
   1. 有多少个优化的阶段参数?
   2. 每个阶段参数都是什么意思? 在什么场景下使用哪些优化阶段的参数?
4. 为什么在构建查询序列的时候, 要使用 Finish_LOJ_Transform 来做优化阶段的控制?
   1. 从名字看是最后一个阶段
   2. 此前经过的流程是什么?
5. 为什么此时调用JO