Bug #118129 Is the timing of index statistics update asynchronous when changing the column type with an index?
Submitted: 8 May 5:01 Modified: 19 May 11:44
Reporter: takemi banno Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: DDL Severity:S3 (Non-critical)
Version:MySQL 8.0 OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[8 May 5:01] takemi banno
Description:
When we changed the column type of a table containing a large volume of data using parallel ALTER TABLE statements, queries against the modified tables suddenly became slower.

Upon examining the "EXPLAIN" output of the slow queries, we found that the join order between multiple tables and the indexes used were different from the usual execution plans.

After running OPTIMIZE TABLE on some of the modified tables, the execution plans reverted to their original state and performance improved.

Even for the tables where OPTIMIZE TABLE was not executed, the performance of the slow queries eventually returned to normal after some time. Checking the execution plans again, they also had reverted to their usual state.

At the point when the ALTER TABLE operation to change the column type is completed, are the index statistics already updated to reflect the new column type?

As an example, we performed a column type change on a table like the one below:

```sql
CREATE TABLE example_NNN (
 pk1  VARCHAR(64) NOT NULL,
 pk2  VARCHAR(64) NOT NULL,
 pk3  VARCHAR(64) NOT NULL,
 val1 VARCHAR(64) NOT NULL,
 val2 VARCHAR(64) NOT NULL,
 val3 VARCHAR(64) NOT NULL,
 PRIMARY KEY (pk1,pk2,pk3),
 INDEX (val1,pk3),
 INDEX (val2,pk3),
 INDEX (val3,pk3) );

ALTER TABLE example_NNN 
 MODIFY COLUMN pk3 enum('ONE', 'TWO', 'THREE');
```

How to repeat:
none
[19 May 11:44] MySQL Verification Team
Hi,

This is a normal behavior. When you alter the table the analysis data is modified too so it can take a bit to gather new one. Running optimize does speed things up.