ANALYZE TABLE INDEX failed

Translated
1

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

Original topic: ANALYZE TABLE INDEX 失败

| username: 梦想是个厨子

Version: v6.1.0
Issue Description: Created an index in the morning, and then the dashboard was spammed with
ANALYZE TABLE $tablename INDEX $indexname;.

image
image1380×490 43.3 KB

Checked
SHOW ANALYZE STATUS;
The status is runtime error: slice bounds out of range [-1:].

image
image1380×526 376 KB

Health graph

image
image1380×456 63.9 KB

Error log:

image
image1380×72 27.7 KB

How to solve this???

2
| username: buddyyuan | Original post link

It looks like this issue.

3
| username: 梦想是个厨子 | Original post link

It seems like it, but I don’t know how to solve it.

4
| username: WalterWj | Original post link

Admin, please check if the index data matches. If not, try rebuilding the index to see if it works.

5
| username: 梦想是个厨子 | Original post link

After deleting the newly created index, ANALYZE TABLE $tablename fails.

6
| username: db_user | Original post link

Try running ANALYZE TABLE manually. If it succeeds manually, the subsequent automatic runs should generally work as well.

7
| username: 梦想是个厨子 | Original post link

Both manual and automatic operations report errors.

8
| username: db_user | Original post link

Looking at the issue on GitHub, there is currently no solution.

As a temporary fix, you can control the auto_analyze time to a very short duration to solve the frequent screen refresh issue.

Additionally:
You can create a table with the same structure and then transfer the data over to see if manual analyze works normally. If it does, you can use table deletion and renaming to bypass this issue.

9
| username: 梦想是个厨子 | Original post link

In the evening, I will try to use alter table $TABLENAME engine=innodb; to rebuild the table. Let’s see if it solves the issue. Creating a table, importing data, and then renaming it will affect normal business operations.

10
| username: db_user | Original post link

The “alter” command might not be very effective. Using “engine=innodb” is just a compatible syntax and probably won’t achieve MySQL’s space reclamation or other functions. Rebuilding the table during a low business peak period and using CDC routing synchronization can minimize business impact.

You can also set automatic analyze to a few minutes and then manually write a script to analyze it first.

11
| username: WalterWj | Original post link

It doesn’t work, try upgrading. It feels like a bug.