思考

• 对于 information_schema.optimizer_trace 这种从内存中获取信息的表，为什么不使用函数，类似 pg 的实现

  • MySQL 有函数可以返回一个自定义类型吗，或者 MySQL 支持定义类型吗
  • pg 是因为支持自定义类型，再或者其函数定义比较简单，函数可以非常方便的关联到具体的内部的某个 function 上，而 MySQL 有类似的行为吗，使用 udf 吗
  • duckdb 也有类似的支持，但是他主要是嵌入式，所以直接编写对应的函数，实现对应的接口，直接 register 就可以了，也是非常轻量级

• MySQL debug 和非 debug 的在某些实现上有非常明显的区别，MySQL 看起来非常注重内核的可观测性，但是有部分实现为了实现这种可观测性，进行了一些额外的修改

  • my_mutex_t 为了方便 debug 实现了 m_native 和 m_safe_ptr，如何保证他们之间一定没有任何逻辑上的差异

• limit 只能限定常量

• 优化之后的执行计划是什么，对比 pg，优化之后的树形结构是 Path tree，之后再 createplan 得到 Plan。MySQL 对应的是什么

  • pg 处理之后是 Path tree，之后再 createplan 得到 Plan
  • MySQL 在 create_access_paths 之后得到 AccessPath tree，之后由 CreateIteratorFromAccessPath 得到 RowIterator

• MySQL 和 pg 的 join order 的差异

  • MySQL make_join_pan Optimize_table_order --> choose_table_order 使用贪婪算法选择 join order
    • 但是这里计算的是 JOIN_TAB array 的顺序，此时每个 table 的具体的 accesspath 和join的具体算法还没有确定，怎么保证当前的顺序在后续生成 path 的过程中，不会导致执行计划劣化，当前步骤中，cost 计算的时候有考虑这个问题吗
      • 有考虑表的内在属性，例如 sort，关联条件的选择率等
      • MySQL 没有 merge join(几十年了，这种基础操作都还没有)
  • pg 是自底向上的 dp，每次选择join的时候，同时会选择具体的 join 算法，然后决定具体的join顺序

• setop 会调用 create_tmp_table，这个操作真的是建立一张临时表吗，这个操作没有使用 cost 判断吗，而且 MySQL 中的block op没有 bufer 管理，只能用临时表吗

• 抽象还不如不抽，抽的难以理解