Optimizer trace RFC

Repo:

Tidb： https://github.com/yisaer/tidb/tree/2022_hackathon

Dashboard: https://github.com/baurine/tidb-dashboard/tree/optimizer-trace

团队

队伍名: 彦青说得队

队长: 高松

队员: 张彦青，黄宝灵

项目介绍

Optimizer trace 是为了将 tidb 优化器在做逻辑优化与物理优化的决策时，将优化器的决策过程以及涉及到的数据与参数通过可视化的方式暴露出来。​

逻辑优化

在逻辑优化阶段，我们的想法是：

1.
针对每一条 rule 变化时，记录下变化前和变化后逻辑计划，从而能追踪与比较 rule 变化前后的 plan 变更。​

2.
在每一条 rule 变化时，记录内部具体执行的动作和理由，比如在 aggregationEliminator 中记录是否执行了 distinctEliminate 与 aggregationEliminate​

最终在逻辑优化方面，我们希望用户能够看到的是类似以下的可视化效果，从而知道在逻辑优化过程中，整个算子树的变化过程:​

common.docs_name - LarkCCM_Docs_Menu_Image

物理优化

在物理优化阶段，优化器会基于逻辑优化后的计划树，以节点和 property 为状态，进行一次树形动态规划，以求出代价最小的物理计划树。也就是说，追踪物理优化阶段即是追踪树形动态规划的过程。保留数据时，只需要保存动态规划状态表和转移路径即可。​

同时，从实际的角度出发，相比于逻辑优化我们更关注整个 Plan Tree 的演变过程，在物理优化阶段我们更加关注某些关键算子是如何选择出他的 bestPlan 的过程，比如 Datasource 的索引选择，Join 算子的算法选择等等。因此，我们在物理优化的 trace 阶段，对于单个算子的 findBestTask 过程中，对于每个候选者而言，我们会记录他的单个 property, cost 和子节点(非递归)的 property 以及它们的 cost，并以此将每个算子的所有候选者都记录下来。​

背景动机

为了方便跟踪优化器所做出的各种决策，以及了解优化器在做决策时所经历的情况，我们可以通过 optmize trace 对优化器决策过程进行可视化来方便我们得知以上信息，这能进一步帮助我们在诊断复杂 SQL 时，或者排查索引选择、Join 算法选择这些关键的算子节点时，提供便利性和可视化诊断方案。​

项目设计

由于项目仅设计 tidb 优化器的内部阶段，所以所有代码修改只会在优化器内部。​

Optimizer trace RFC​

Optimizer trace RFC