V6.5.0 SQL Execution Plan

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: v6.5.0 sql执行计划

| username: jackerzhou

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version] v6.5.0
[Reproduction Path]
[Encountered Problem: Problem Phenomenon and Impact] After migrating from MySQL to TiDB, the execution time of the same statement has increased. TiDB has added new operators - Selection_149 (Probe), Selection_81 (Build). What are the meanings of build and probe respectively?
[Resource Configuration]

[Attachments: Screenshots/Logs/Monitoring]

| username: Kongdom | Original post link

You can refer to the official documentation:

In the execution plan results, starting from version v6.4.0, the meaning of the estRows field for specific operators (i.e., the Probe side of IndexJoin and Apply operators) is different from versions prior to v6.4.0.

Before v6.4.0, estRows represented the number of rows the Probe side was expected to process for each row of the Build side sub-node. Starting from v6.4.0, estRows represents the total number of rows the Probe side is expected to process. Since the actual number of rows displayed in EXPLAIN ANALYZE (the actRows column) represents the total number of rows, the meaning of estRows for these operators has been consistent with the meaning of the actRows column since v6.4.0.

| username: weixiaobing | Original post link

It is recommended to post the complete execution plan and check if the table statistics need to be re-collected.

| username: jackerzhou | Original post link

Thanks for the support, master. By optimizing the apply algorithm in parallel and enabling the tidb_enable_parallel_apply parameter, the execution time has been reduced from 5 seconds to less than 1 second.

| username: Kongdom | Original post link

:+1: :+1: :+1:

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.