Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 执行计划中的一些特殊数字是什么含义？
|
username: 春风十里
Some special numbers in the execution plan, such as 28, 29, 31 in the execution plan below, seem to be used to identify the corresponding tables or operations in the plan. But why are they 28 and 29 instead of 1 or 2? What does this mean?
It doesn’t have any practical significance; it’s just an identifier. Internally, each operator is assigned a number. Additionally, due to parallel processing, it doesn’t necessarily represent the order of execution.
Is it related to the order? I don’t think so, I’ve never paid attention to this.
Overall, it’s just an identifier and has nothing to do with order, but if you look closely, for most parent-child relationship operators, it still represents order.
This number should not be the execution order, but rather the sequence number. For this example, the execution order should be 31->32->29->30->28->13.
I understand that it is a sequence number, similar to MySQL’s id or Oracle’s id. But why does this sequence number not start from 0 or 1, but from the middle, and some numbers are missing?
For example, MySQL execution plan:
Or Oracle execution plan:
Both start from 1 or 0, but TiDB’s execution plan sequence number seems to start from the middle, and there are gaps. I don’t quite understand what the missing numbers are.
It is possible that the fewer ones are executed in parallel, for example, executed on 3 TiKV separately, each TiKV needs to assign a sequence number, but logically it is just one execution plan with only one sequence number.
Or some internal execution content is assigned a sequence number.
It’s possible, but I couldn’t find any corresponding explanation in the official documentation.
I understand that the identifiers, the numbers, should be meaningful to help us explain the actual order of execution plans (not the numerical order). However, TiDB’s display makes it easy for me to associate that the numbers in the middle have done some other operations?
The serial number is definitely not the execution order; I understand it as an identifier. For this example, the execution order should be 31->32->29->30->28->13. The execution order is very important, and many times an incorrect execution plan starts with the first execution. It is crucial to determine the content of the first execution in the execution plan.
You’re right, I took it for granted.
Normally, it should first build (31->32) the hash table and then execute the probe (29->30).
The execution plan is read from top to bottom, from right to left. I feel that the numbers are not very meaningful.
Okay, this can be confirmed as an identifier. There is another issue, which is the problem of non-continuous identifiers.
This number is an identifier assigned to each operator during the internal implementation of processing a task within the TiDB cluster. These operators may be categorized and numbered based on different functionalities.
The system then displays a portion of these operators related to the execution plan to the user, along with their numeric identifiers. When users view the execution plan, they don’t need to pay attention to these numeric identifiers, as they don’t hold much significance from an external perspective. Users only need to focus on the tree structure and execution order of the execution plan.
Okay. For operator identification, I think it might be better to display them sequentially like MySQL IDs if we want to show them.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: