Analysis of Slow SQL Execution: How to Identify the Cause of Long Pre-execution Time

Translated
1

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

Original topic: 慢sql执行分析，前序执行耗时较长，如何定位原因

| username: TiDBer_20QjYTLl

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version] v6.5.1
[Reproduction Path]
[Encountered Problem: Problem Phenomenon and Impact] When entering the TiDB Dashboard slow query analysis interface and viewing the execution time analysis of slow queries, it is found that the execution time of many “insert on duplicate key” type SQLs is mostly spent on the pre-execution time. Could you please explain the reason for this?

2
| username: tidb菜鸟一只 | Original post link

How many unique indexes are there on the corresponding table?

3
| username: zhanggame1 | Original post link

You can trace this SQL.

4
| username: TiDBer_20QjYTLl | Original post link

There is only one unique index.

5
| username: TiDBer_20QjYTLl | Original post link

It’s not slow when tracing.

6
| username: zhanggame1 | Original post link

You can take a look at this, see if there are any optimization reference points.

7
| username: TiDBer_20QjYTLl | Original post link

The key is what the metric “long pre-execution time” represents, and which stage it indicates is taking a long time.

8
| username: redgame | Original post link

Use TiDB’s built-in slow query log or APM tools (such as TiDB Dashboard or TiDB Monitor) to monitor the performance of the TiDB cluster and see what happened.

9
| username: system | Original post link

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