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.
  
 
 
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.