Large Execution Time Discrepancy in Execution Plans

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

Original topic: 执行计划执行时间差距大

| username: wakaka

【TiDB Usage Environment】Production Environment
【TiDB Version】5.0.6
【Reproduction Path】Operations performed that led to the issue
【Encountered Issue: Phenomenon and Impact】The execution time for the same execution plan varies greatly, and different execution plans have varying speeds. It’s unclear which execution plan is optimal. For example, the execution plan “a76a4c820c103f1cb02d1f6d704f9835f5d2ea5b949d9733abb4bd260d44b574” on 11-07 took 13 seconds, while the same plan on 11-08 took only 1 second.
【Resource Configuration】
【Attachments: Screenshots/Logs/Monitoring】



| username: 胡杨树旁 | Original post link

You can check the SQL statement analysis on the dashboard, where it shows the maximum, minimum, and average time.

| username: alfred | Original post link

The same execution plan taking different amounts of time is generally related to the resource consumption of the specific SQL. For example, different variables substituted in the SQL can lead to variations in the amount of data processed, resulting in higher resource consumption and increased time. You can check if there is a better execution plan or optimize the SQL.

| username: Kongdom | Original post link

Is the data volume consistent? Is the table health consistent?

| username: wakaka | Original post link

The query variables are consistent multiple times.

| username: wakaka | Original post link

Multiple queries have consistent variables, and the time interval is no more than a few minutes. I also considered the health issue, but at 16:36:06, it took 13s, 6s, and 5s at the same moment.

| username: 胡杨树旁 | Original post link

Is the execution plan the same if the execution time is different?

| username: alfred | Original post link

Do a trace to see which step has the time difference.

| username: wakaka | Original post link

Currently, everything is very fast, less than 2 seconds. However, there is a situation where the same execution plan has a significant difference in performance, which I don’t quite understand.

| username: wakaka | Original post link

The plan_digest is the same.

| username: 胡杨树旁 | Original post link

Could you please tell me how to do this trace?

| username: alfred | Original post link

| username: 胡杨树旁 | Original post link

Okay, thank you.

| username: buddyyuan | Original post link

There are several scenarios:

  1. The execution plan is consistent, but the amount of data queried is inconsistent.
  2. The execution plan is consistent, but there may be blockages in other areas. Specifically, you need to check the statement execution time on the dashboard to see which part is consuming the most time.
| username: wakaka | Original post link

  1. Confirmed that the parameters are the same and executed at the same time.
  2. At the same moment, I also checked the monitoring and found nothing unusual.
| username: wakaka | Original post link

The same plan_digest shows a significant difference at the same time.

| username: alfred | Original post link

Is there such a big difference in execution time for running the exact same SQL?

| username: buddyyuan | Original post link

Directly click on the dashboard, open the slow queries, find these specific time points, and check each one individually. Look at the SQL execution time tab to see where the time is being spent, and compare them.

| username: Jiawei | Original post link

  1. Where are the differences in the execution times of these SQL queries on the dashboard?
  2. Check if there were any other SQL queries at that time causing the current SQL to be blocked, i.e., related to locks.
| username: wakaka | Original post link

Yes, many reports have this issue. They run 99% of the time without problems, but there are a dozen times when they are slow. I took the MD5 of the query, and the two execution statements and execution plans are the same. The difference is 5 seconds.