In TiDB, the process of SQL optimization consists of two phases: logical optimization and physical optimization. This document describes the logical and physical optimization to help you understand the whole process.
Based on rules, logical optimization applies some optimization rules to the input logical execution plan in order, to make the whole logical execution plan better. The optimization rules include:
Based on cost, physical optimization makes the physical execution plan for the logical execution plan generated in the previous phase.
In this phase, the optimizer selects the specific physical implementation for each operator in the logical execution plan. Different physical implementations of logical operators differ in time complexity, resource consumption, physical properties, and so on. During this process, the optimizer determines the cost of different physical implementations according to data statistics, and selects the physical execution plan with the minimum whole cost.
The logical execution plan is a tree structure and each node corresponds to a logical operator in SQL. Similarly, the physical execution plan is also a tree structure, and each node corresponds to a physical operator in SQL.
The logical operator only describes the function of an operator, while the physical operator describes the concrete algorithm that implements this function. A single logical operator might have multiple physical operator implementations. For example, to implement
LogicalAggregate, you can use either
HashAggregate the of the hash algorithm, or
StreamAggregate of the stream type.
Different physical operators have different physical properties, and have different requirements on the physical properties of their subnodes. The physical properties include the data’s order, distribution, and so on. Currently, only the data order is considered in TiDB.
What’s on this page