After upgrading to 8.1, there is an additional slow query with just a ";" (semicolon) as the SQL statement and no user information

Translated
1

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

Original topic: 升级到8.1之后，多了1个慢查询，sql语句就一个“；”（分号），无用户信息。

| username: TiDBer_rrt4FOef

[TiDB Usage Environment] Production Environment
[TiDB Version] v8.1.0
[Reproduction Path]
[Encountered Problem]
Around midnight (June 13th), we performed a version upgrade on TiDB from v6.5.0 to v8.1.0 without stopping the service. The upgrade process went smoothly without any error messages. After the upgrade, connections were normal, and all systems were running stably.

In the morning, while observing slow queries on the Dashboard, I noticed a strange slow query. The statement was just a semicolon “;”, and it executed every 10 minutes or so, with memory usage fluctuating significantly. The basic information did not show the executing database, username, or client address.

I checked the CLUSTER_SLOW_QUERY in INFORMATION_SCHEMA, and this statement only appeared after the upgrade. It was not present in the slow queries before the upgrade. Is this automatically executed by the database? Is this phenomenon normal?

[Attachments: Screenshots/Logs/Monitoring]

cgi-bin_mmwebwx-bin_webwxgetmsgimg_&MsgID=1774899930854467649&skey=@crypt_429ba5d2_1f949a46ff612dfb115ba38d59738cee&mmweb_appid=wx_webfilehelper
cgi-bin_mmwebwx-bin_webwxgetmsgimg_&MsgID=1774899930854467649&skey=@crypt_429ba5d2_1f949a46ff612dfb115ba38d59738cee&mmweb_appid=wx_webfilehelper748×1000 117 KB

cgi-bin_mmwebwx-bin_webwxgetmsgimg_&MsgID=5728688655581766273&skey=@crypt_429ba5d2_1f949a46ff612dfb115ba38d59738cee&mmweb_appid=wx_webfilehelper
cgi-bin_mmwebwx-bin_webwxgetmsgimg_&MsgID=5728688655581766273&skey=@crypt_429ba5d2_1f949a46ff612dfb115ba38d59738cee&mmweb_appid=wx_webfilehelper748×1000 86.1 KB

2
| username: zhaokede | Original post link

Looking at the index name in this line, there is a tidb_background_subtask:idx_exec_id. Is it the database’s background subtask performing index optimization?

3
| username: zhaokede | Original post link

idx_exec_id: This part may be related to index execution. It could be an identifier used to identify a specific index creation, modification, or deletion operation.

4
| username: Kongdom | Original post link

:thinking: There’s only one semicolon, and there’s still a HashJoin in the execution plan? Can you share the complete execution plan?
image

5
| username: TiDBer_rrt4FOef | Original post link

There are about sixty slow SQL records like this one, and most of the records do not have an execution plan. Looking at the warning column, many of them have information similar to the following:

Analyze use auto adjusted sample rate 0.034xxx for db.table_name, reason to use this rate is "Row count in stats_meta is smaller compared with the row count got by PD, use min(1,15000/4.385493e+06) as the sample-rate=0.034xxxxxx"

It is guessed that these are some analysis tasks of the database itself. After they were executed, they did not appear in the slow query log this afternoon.

6
| username: 林夕一指 | Original post link

It looks like it’s collecting statistics, but I remember the background task for statistics is just one SQL; I really don’t know.

7
| username: Kongdom | Original post link

:thinking: We can only wait for the experts from the original manufacturer to take a look.

8
| username: Kongdom | Original post link

For example, this execution plan, could it be that the SQL is too long, and there are line breaks in the SQL, so after truncation, only the line break semicolon is left :yum:

9
| username: 小龙虾爱大龙虾 | Original post link

How about checking the file?

10
| username: TiDBer_mra9oJ0k | Original post link

I also encountered this situation after upgrading from 7.5 to 8.1.

11
| username: 这里介绍不了我 | Original post link

Pay attention and study it.

12
| username: ziptoam | Original post link

This issue is very strange. Even for tasks generated by the database itself, such as indexing or analysis, it is not appropriate to use such an imprecise way of representation.

13
| username: zhaokede | Original post link

It is an automated index optimization analysis background task of the system.

14
| username: 扬仔_tidb | Original post link

Could it be a display bug in the dashboard?

15
| username: h5n1 | Original post link

Sorry, I can’t assist with that.

16
| username: Kongdom | Original post link

:flushed: It turns out it really is a BUG, we can wait for the fix version.

The issue has been confirmed in version v8.1.0.

image
image972×278 16 KB

17
| username: zhanggame1 | Original post link

It obviously looks like a bug.

18
| username: Hacker007 | Original post link

Copying the original SQL also only has one ;?

19
| username: 友利奈绪 | Original post link

Let’s wait for the subsequent fixes. 2333

20
| username: Jellybean | Original post link

From the value of “whether it is an internal SQL query” being 1, we can infer that this is a statement within the TiDB cluster, indicating an issue with the cluster itself and not a business-side SQL issue.

The solution, as mentioned in the issue links provided earlier, is to wait for the official fix and then make adjustments. Stay tuned for updates.