Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 从截图中能否看出sql语句执行花销时间？
|
username: yulei7633
I can’t view images directly. Please provide the text you need translated.
|
username: yulei7633
|
username: 
|
username: 
|
username: 
|
username: The execution info contains it, but this is an estimated time and is not accurate.
|
username: 
|
username: Is the time here cumulative or does it refer to the top time: 86.9ms?
What is the time relationship here? Is the time in this SQL statement the cumulative value of these times or does it refer to the top time: 86.9ms?
Looking at the time in here, if we only consider the time for delete_5 which is 86.9ms, I’m not sure if it’s the cumulative time for each row? The entire SQL takes just this amount of time. But in the slow query log, it shows that this statement took 330ms?
|
username: It might be caused by other statements, check the backoff.
|
username: The process of explain analyze can confirm the execution time consumption of each step.
If it is a slow query SQL, you can log in to the cluster’s Dashboard to view the SQL statement analysis or the slow query section. The visualization there is quite well done, allowing you to easily see whether the slowness is due to the computation layer or the storage layer, making it very convenient and user-friendly.
The time in here is completely inconsistent with the time in the screenshot I posted. What’s the issue?
Is this SQL executed many times? It is possible that the SQL in your screenshot is not the same execution as the one you clicked on in the Dashboard.
From the Dashboard screenshot you posted, the time taken to generate the execution plan is too long. The SQL execution time is 302ms, while generating the execution plan took 209ms, accounting for nearly 70% of the total time, which is clearly abnormal.
You might want to focus on monitoring the resource usage of the tidb-server, running logs, and other related metrics.
Your tidb-server has an issue, possibly due to insufficient memory. Normally, generating an execution plan should be very quick.
I only took a screenshot of one of them; all the slow queries are like this.
So it’s no longer an issue with a specific SQL query. If the problem is that generating the execution plan is slow across the board, then it’s an issue with the overall resources of your TiDB server.
My table is quite special, it has 4500 columns. Could this be related?
That definitely has an impact. The more fields parsed, the slower it will be. I suggest you enable the non-Prepare statement execution plan cache with:
SET global tidb_enable_non_prepared_plan_cache = ON;
This way, SQL statements won’t be parsed every time, and the execution plan can be directly retrieved from the execution plan cache, skipping the re-execution plan step.