Description:
When we executed a DML SQL, and commit the transaction, the value for field update_time for information_schema.tables is changed to be a valid datetime string, like 2023-06-18 21:53:06.
After that, shutdown the MySQL, and start it.
When we logined to MySQL again, and execute the SQL: analyze table <table_name>, the value of update_time was changed to be NULL, that is to say: it has lost.
How to repeat:
1. Login to MySQL
2. Execute the SQL: set information_schema_stats_expiry = 5
3. Execute the SQL: create database test default charset utf8
4. Execute the SQL: use test
5. Execute the SQL: create table t_update_time(id int auto_increment primary key, str1 varchar(64)) engine = InnoDB default charset utf8
6. Execute the SQL: insert into t_update_time(str1) values ('s1')
7. Execute the SQL: select table_schema, table_name, update_time from information_schema.tables where table_schema = 'test' and table_name = 't_update_time'
The result is:
+--------------+---------------+---------------------+
| TABLE_SCHEMA | TABLE_NAME | UPDATE_TIME |
+--------------+---------------+---------------------+
| test | t_update_time | 2023-06-18 21:41:23 |
+--------------+---------------+---------------------+
8. Shutdown the MySQL, and then start it
9. Login to MySQL
10. Execute the SQL: analyze table test.t_update_time
11. Execute the SQL: select table_schema, table_name, update_time from information_schema.tables where table_schema = 'test' and table_name = 't_update_time'
The result is:
+--------------+---------------+-------------+
| TABLE_SCHEMA | TABLE_NAME | UPDATE_TIME |
+--------------+---------------+-------------+
| test | t_update_time | <null> |
+--------------+---------------+-------------+
Suggested fix:
If this is confirmed to be a bug, I will be glad to fixed it.