The entity set of the query and the entity set contained in the query plan must be the same.
If you create a CF with a join of entities A and B, the records may be missing. As a result, the result obtained from the CF with A and B does not match the result directly derived from the original A.
This problem can be solved by creating a CF with all constraints created by outer join when collecting data from MySQL.
This allows you to get only B.f2, B.key from [A. key, A. f1] [B.f2] - > [B. key] and create a CF like [B. key] [] - > [B.f2]
In many cases, data for time t + 1 is obtained using the query plan for time t.
However, in some cases, the query plan may be terminated at the middle step.
Coexistence with an existing migrate plan
If only a new migrate plan is used, the plan cannot be recommended if the newly created CF has attributes that are not included in other query plans. Therefore, coexistence with the old prepare plan is required.
(failed) We try to implement a policy of combining multiple trees into one tree, but the plans in the tree cannot be constrained unless they all have the same entity set.
Create multiple prepare plan trees for each CF you want to migrate and use only one plan from one of them when migrating
Filter step, sort step, aggregation step would be removed, cost recalculation needed
The equation is divided into two stages. Put another variable in the same position as migrate_var in the current code, for each migrate_var, Sum of related migrate_plan_var == migrate_var
Y-Wakuta
commented
4 years ago 
Propose a new migrate plan specification
B.f2, B.keyfrom[A. key, A. f1] [B.f2] - > [B. key]and create a CF like[B. key] [] - > [B.f2]Coexistence with an existing migrate plan
Sum of related migrate_plan_var == migrate_var