information_schema.tables 视图中，update_time 字段记录了表的最后修改时间，即某个表最后一次插入、更新、删除记录的事务提交时间。
update_time 字段有个问题，就是它记录的表的最后修改时间不一定靠谱。
(相关资料图)
从省事的角度来说，既然它太不靠谱，我们不用它就好了。
但是，本着不放过一个坏蛋，不错过一个好蛋的原则，我们可以花点时间，摸清楚它的底细。
接下来，我们围绕下面 2 个问题，对 update_time 做个深入了解：
它记录的表的最后修改时间从哪里来？它为什么不靠谱？本文基于 MySQL 8.0.32 源码，存储引擎为 InnoDB。
一、准备工作创建测试表：
USE test;CREATE TABLE t1 (id int unsigned NOT NULL AUTO_INCREMENT,i1 int DEFAULT "0",PRIMARY KEY (id) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;插入测试数据：
INSERT INTO t1(i1) VALUES (10), (20), (30);顺便看一眼 information_schema.tables 视图的 update_time 字段：
-- 第 1 步：设置缓存时间为 0-- 忽略 mysql.table_stats 中-- 持久化的 update_time 字段值-- 直接从 InnoDB 中获取-- update_time 字段的最新值SET information_schema_stats_expiry = 0;-- 第 2 步：执行查询SELECT * FROM information_schema.tablesWHERE table_schema = "test"AND table_name = "t1"\GTABLE_CATALOG | defTABLE_SCHEMA | testTABLE_NAME | t1TABLE_TYPE | BASE TABLEENGINE | InnoDBVERSION | 10ROW_FORMAT | DynamicTABLE_ROWS | 3AVG_ROW_LENGTH | 5461DATA_LENGTH | 16384MAX_DATA_LENGTH | 0INDEX_LENGTH | 0DATA_FREE | 6291456AUTO_INCREMENT | 4CREATE_TIME | 2023-06-18 15:49:17UPDATE_TIME | 2023-06-18 15:50:37CHECK_TIME | CREATE_OPTIONS |TABLE_COMMENT |因为系统变量 information_schema_stats_expiry 的值已经设置为 0，所以能够读取到 t1 表最新的 update_time。
上面查询结果中，update_time 就是插入测试数据的事务的提交时间。
二、来龙去脉1、标记表发生了变化某个表插入、更新、删除记录的过程中，写 undo 日志之前，trx_undo_report_row_operation() 会先记下来这个表的数据发生了变化：
// storage/innobase/trx/trx0rec.ccdberr_t trx_undo_report_row_operation(...){...bool is_temp_table = index->table->is_temporary();...if (!is_temp_table) {trx->mod_tables.insert(index->table);}...}有一点需要说明：只有非临时表的数据发生变化，才会被标记。对于临时表，就不管了。
trx->mod_tables 是个集合，类型是 std::set，定义如下：
// storage/innobase/include/trx0trx.h// 为了方便阅读，这个定义经过了格式化typedef std::set,ut::allocator>trx_mod_tables_t;// storage/innobase/include/trx0trx.hstruct trx_t {...trx_mod_tables_t mod_tables;...} 集合中保存的是 InnoDB 表对象的指针 dict_table_t *，dict_table_t 结构体的 update_time 属性用于保存表的最后修改时间：
// storage/innobase/include/dict0mem.hstruct dict_table_t {.../** Timestamp of the last modification of this table. */// 为了方便阅读，这个定义经过了格式化std::atomicupdate_time;...} trx_undo_report_row_operation() 只会标记表的数据发生了变化，不会修改表的 dict_table_t 对象的 update_time 属性。
2、确定变化时间// storage/innobase/trx/trx0trx.ccdberr_t trx_commit_for_mysql(trx_t *trx) /*!< in/out: transaction */{ ... // 获取事务状态 switch (trx->state.load(std::memory_order_relaxed)) { ... // 事务为活跃状态 case TRX_STATE_ACTIVE: // 事务处于二阶段提交的 PREPARE 阶段 case TRX_STATE_PREPARED: trx->op_info = "committing"; ... // 说明是读写事务 if (trx->id != 0) { // 确定表的最后修改时间 trx_update_mod_tables_timestamp(trx); } trx_commit(trx); MONITOR_DEC(MONITOR_TRX_ACTIVE); trx->op_info = ""; return (DB_SUCCESS); case TRX_STATE_COMMITTED_IN_MEMORY: break; } ...}读写事务提交时，trx_commit_for_mysql() 调用 trx_update_mod_tables_timestamp()，把当前时间保存到表的 dict_table_t 对象的 update_time 属性中。
// storage/innobase/trx/trx0trx.ccstatic void trx_update_mod_tables_timestamp(trx_t trx) /!< in: transaction */{...// 获取当前时间const auto now = std::chrono::system_clock::from_time_t(time(nullptr));trx_mod_tables_t::const_iterator end = trx->mod_tables.end();// 迭代 trx->mod_tables 集合中的每个表for (trx_mod_tables_t::const_iterator it = trx->mod_tables.begin(); it != end;++it) {// 把当前时间赋值给 dict_table_t 对象// 的 update_time 属性(*it)->update_time = now;}trx->mod_tables.clear();}trx->mod_tables 中保存的是数据发生变化的表的 dict_table_t 对象指针，for 循环每迭代一个对象指针，都把该对象的 update_time 属性值设置为当前时间。
这就说明了 update_time 属性中保存的表的最后修改时间是执行 DML SQL 的事务提交时间。
循环结束之后，清空 trx->mod_tables 集合。
执行流程进行到这里，表的最后修改时间还只是存在于它的 dict_table_t 对象中，也就是仅仅位于内存中。
此时，如果某个（些）表的 dict_table_t 对象被从 InnoDB 的缓存中移除了，它（们）的 update_time 也就丢失了。
如果发生了更不幸的事：MySQL 挂了，或者服务器突然断电了，所有表的 update_time 属性值就全都丢失了。
那要怎么办呢？当然只能是持久化了。
3、持久化dict_table_t 对象的 update_time 属性值，会被保存（持久化）到 mysql.table_stats 表中，这个操作包含于表的统计信息持久化过程中，有两种方式：
主动持久化。被动持久化。（1）主动持久化analyze table
我们把这种场景称为主动持久化，部分堆栈如下：
| > mysql_execute_command() sql/sql_parse.cc:4688| + > Sql_cmd_analyze_table::execute() sql/sql_admin.cc:1735| + - > mysql_admin_table() sql/sql_admin.cc:1128| + - x > handler::ha_analyze(THD*, HA_CHECK_OPT*) sql/handler.cc:4783| + - x = > ha_innobase::analyze(THD*, HA_CHECK_OPT*) storage/innobase/handler/ha_innodb.cc:18074| + - x = | > ha_innobase::info_low(unsigned int, bool) storage/innobase/handler/ha_innodb.cc:17221| + - x > info_schema::update_table_stats(THD*, Table_ref*) sql/dd/info_schema/table_stats.cc:338| + - x = > setup_table_stats_record() sql/dd/info_schema/table_stats.cc:179| + - x = > Dictionary_client::store() sql/dd/impl/cache/dictionary_client.cc:2595| + - x = | > Storage_adapter::store() sql/dd/impl/cache/storage_adapter.cc:334| + - x = | + > dd::Weak_object_impl_::store() sql/dd/impl/types/weak_object_impl.cc:106| + - x = | + - > Table_stat_impl::store_attributes() sql/dd/impl/types/table_stat_impl.cc:81 ha_innobase::analyze() 调用 ha_innobase::info_low()，从 dict_table_t 对象中获取 update_time 属性值（即表的最后修改时间）。
// storage/innobase/handler/ha_innodb.ccint ha_innobase::info_low(uint flag, bool is_analyze) {dict_table_t *ib_table;...if (flag & HA_STATUS_TIME) {...stats.update_time = (ulong)std::chrono::system_clock::to_time_t(ib_table->update_time.load());}...}ib_table 是 dict_table_t 对象，事务提交过程中，trx_update_mod_tables_timestamp() 会把事务提交时间保存到 ib_table->update_time 中。
这里，dict_table_t 对象的 update_time 属性值会转移阵地，保存到 stats 对象中备用，stats 对象的类型为 ha_statistics。
说到备用，我马上想到的是教人做菜的节目，比如：炸好的茄子捞出沥油，放在一旁备用。你想到了什么？
// sql/dd/info_schema/table_stats.ccbool update_table_stats(THD *thd, Table_ref *table) {// Update the object propertiesHA_CREATE_INFO create_info;TABLE *analyze_table = table->table;handler *file = analyze_table->file;// ha_innobase::info()if (analyze_table->file->info(HA_STATUS_VARIABLE |HA_STATUS_TIME |HA_STATUS_VARIABLE_EXTRA |HA_STATUS_AUTO) != 0)return true;file->update_create_info(&create_info);// 构造 Table_stat 对象std::unique_ptr ts_obj(create_object());// 为 Table_stat 对象的各属性赋值setup_table_stats_record(thd, ts_obj.get(),dd::String_type(table->db, strlen(table->db)),dd::String_type(table->alias, strlen(table->alias)),file->stats, file->checksum(),file->ha_table_flags() & (ulong)HA_HAS_CHECKSUM,analyze_table->found_next_number_field);// 持久化return thd->dd_client()->store(ts_obj.get()) &&report_error_except_ignore_dup(thd, "table");} update_table_stats() 调用 ha_innobase::info()，从 InnoDB 中获取表的信息。
ha_innobase::info() 会调用 ha_innobase::info_low()，把 dict_table_t 对象的 update_time 属性值保存到 stats 对象中（类型为 ha_statistics），也就是上面代码中的 file->stats。
这是 update_time 属性值第 1 次转移阵地：
dict_table_t -> ha_statisticsanalyze 过程中，ha_innobase::analyze()、ha_innobase::info() 都会调用 ha_innobase::info_low()，看起来是重复调用了，不过，这两次调用的参数值不完全一样，我们就不深究了。
create_object
inline void setup_table_stats_record(THD *thd, dd::Table_stat *obj, ...) {...// stats 的类型为 ha_statisticsif (stats.update_time) {// obj 的类型为 Table_statobj->set_update_time(dd::my_time_t_to_ull_datetime(stats.update_time));}...}setup_table_stats_record() 调用 obj->set_update_time() 把 stats.update_time 赋值给 obj.update_time。
obj 对象的类型为 Table_stat，到这里，update_time 属性值已经是第 2 次转移阵地了：
dict_table_t -> ha_statisticsha_statistics -> Table_statsetup_table_stats_record() 为 Table_stat 对象各属性赋值完成之后，update_table_stats() 接着调用 thd->dd_client()->store()，经过多级之后，调用 Weak_object_impl_
// sql/dd/impl/types/weak_object_impl.cc// 为了方便介绍，我们以 t1 表为例// 介绍表的统计信息持久化过程template bool Weak_object_impl_::store(Open_dictionary_tables_ctx *otx) { ... const Object_table &obj_table = this->object_table(); // obj_table.name() 的返回值为 table_stats // 即 mysql 库的 table_stats 表 Raw_table *t = otx->get_table(obj_table.name()); ... do { ... // 构造主键作为查询条件 // 数据库名：test、表名：t1 std::unique_ptr obj_key(this->create_primary_key()); ... // // 从 mysql.table_stats 表中 // 查询之前持久化的 t1 表的统计信息 std::unique_ptr r; if (t->prepare_record_for_update(*obj_key, r)) return true; // 如果 mysql.table_stats 表中 // 不存在 t1 表的统计信息 // 则结束循环 if (!r.get()) break; // Existing record found -- do an UPDATE. // 如果 mysql.table_stats 表中 // 存在 t1 表的统计信息 // 则用 this 对象中 t1 表的最新统计信息 // 替换 Raw_record 对象中对应的字段值 if (this->store_attributes(r.get())) { my_error(ER_UPDATING_DD_TABLE, MYF(0), obj_table.name().c_str()); return true; } // 把 Raw_record 对象中 t1 表的最新统计信息 // 更新到 mysql.table_stats 表中 if (r->update()) return true; return store_children(otx); } while (false); // No existing record exists -- do an INSERT. std::unique_ptr r(t->prepare_record_for_insert()); // Store attributes. // Table_stat_impl::store_attributes() if (this->store_attributes(r.get())) { my_error(ER_UPDATING_DD_TABLE, MYF(0), obj_table.name().c_str()); return true; } // t1 表的最新统计信息 // 插入到 mysql.table_stats 表中 if (r->insert()) return true; ...} 在代码注释中，我们说明了以 t1 表为例，来介绍 Weak_object_impl_
obj_key 是一个包含数据库名、表名的对象，用于调用 t->prepare_record_for_update() 从 mysql.table_stats 中查询之前持久化的 t1 表的统计信息。
如果查询到了 t1 表的统计信息，则保存到 Raw_record 对象中（指针 r 引用的对象），调用 this->store_attributes()，用 t1 表的最新统计信息替换 Raw_record 对象的相应字段值，得到代表 t1 表最新统计信息的 Raw_record 对象。
这里，update_time 属性值会第 3 次转移阵地：
dict_table_t -> ha_statisticsha_statistics -> Table_statTable_stat -> Raw_record// sql/dd/impl/types/table_stat_impl.ccbool Table_stat_impl::store_attributes(Raw_record *r) {return r->store(Table_stats::FIELD_SCHEMA_NAME, m_schema_name) ||r->store(Table_stats::FIELD_TABLE_NAME, m_table_name) ||r->store(Table_stats::FIELD_TABLE_ROWS, m_table_rows) ||r->store(Table_stats::FIELD_AVG_ROW_LENGTH, m_avg_row_length) ||r->store(Table_stats::FIELD_DATA_LENGTH, m_data_length) ||r->store(Table_stats::FIELD_MAX_DATA_LENGTH, m_max_data_length) ||r->store(Table_stats::FIELD_INDEX_LENGTH, m_index_length) ||r->store(Table_stats::FIELD_DATA_FREE, m_data_free) ||r->store(Table_stats::FIELD_AUTO_INCREMENT, m_auto_increment,m_auto_increment == (ulonglong)-1) ||r->store(Table_stats::FIELD_CHECKSUM, m_checksum, m_checksum == 0) ||r->store(Table_stats::FIELD_UPDATE_TIME, m_update_time,m_update_time == 0) ||r->store(Table_stats::FIELD_CHECK_TIME, m_check_time,m_check_time == 0) ||r->store(Table_stats::FIELD_CACHED_TIME, m_cached_time);}调用 this->store_attributes() 得到 t1 表的最新统计信息之后，Weak_object_impl_
如果 t->prepare_record_for_update() 没有查询到表的统计信息，执行流程在 if (!r.get()) break 处会结束 while 循环。
之后，调用 t->prepare_record_for_insert() 构造一个初始化状态的 Raw_record 对象（指针 r 引用的对象），再调用 this->store_attributes() 把 t1 表的最新统计信息赋值给 Raw_record 对象的相应字段。
最后，调用 r->insert() 把 t1 表的统计信息插入到 mysql.table_stats 中，完成持久化操作。
（2）被动持久化从 information_schema.tables 视图查询一个或多个表的信息时，对于每一个表，如果该表的统计信息从来没有持久化过，或者上次持久化的统计信息已经过期，MySQL 会从 InnoDB 中获取该表的最新统计信息，并持久化到 mysql.table_stats 中。
上面的描述有一个前提：对于每一个表，该表的统计信息需要持久化。
那么，怎么判断 mysql.table_stats 中某个表的统计信息是否过期？
逻辑是这样的：对于每一个表，如果距离该表上一次持久化统计信息的时间，大于系统变量 information_schema_stats_expiry 的值，说明该表的统计信息已经过期了。
information_schema_stats_expiry 的默认值为 86400s。
因为这种持久化是在查询 information_schema.tables 视图过程中触发的，为了区分，我们把这种持久化称为被动持久化。
被动持久化介绍起来会复杂一点点，我们以查询 t1 表的信息为例，SQL 如下：
SELECT * FROM information_schema.tablesWHERE table_schema = "test" ANDtable_name = "t1"\G被动持久化的部分堆栈如下：
| > Query_expression::ExecuteIteratorQuery() sql/sql_union.cc:1763| + > NestedLoopIterator::Read() sql/iterators/composite_iterators.cc:465| + > Query_result_send::send_data() sql/query_result.cc:100| + - > THD::send_result_set_row() sql/sql_class.cc:2878| + - x > Item_view_ref::send() sql/item.cc:8682| + - x = > Item_ref::send() sql/item.cc:8327| + - x = | > Item::send() sql/item.cc:7299| + - x = | + > Item_func_if::val_int() sql/item_cmpfunc.cc:3516| + - x = | + - > Item_func_internal_table_rows::val_int() sql/item_func.cc:9283| + - x = | + - x > get_table_statistics() sql/item_func.cc:9268| + - x = | + - x = > Table_statistics::read_stat() sql/dd/info_schema/table_stats.h:208| + - x = | + - x = | > Table_statistics::read_stat() sql/dd/info_schema/table_stats.cc:457| + - x = | + - x = | + > is_persistent_statistics_expired() sql/dd/info_schema/table_stats.cc:86| + - x = | + - x = | + > Table_statistics::read_stat_from_SE() sql/dd/info_schema/table_stats.cc:563| + - x = | + - x = | + - > innobase_get_table_statistics() storage/innobase/handler/ha_innodb.cc:17642| + - x = | + - x = | + - > Table_statistics::cache_stats_in_mem() sql/dd/info_schema/table_stats.h:163| + - x = | + - x = | + - > persist_i_s_table_stats() sql/dd/info_schema/table_stats.cc:247| + - x = | + - x = | + - x > store_statistics_record() sql/dd/info_schema/table_stats.cc:147| + - x = | + - x = | + - x = > Dictionary_client::store() sql/dd/impl/cache/dictionary_client.cc:2595| + - x = | + - x = | + - x = | > Storage_adapter::store() sql/dd/impl/cache/storage_adapter.cc:334| + - x = | + - x = | + - x = | + > dd::Weak_object_impl_::store() sql/dd/impl/types/weak_object_impl.cc:106 NestedLoopIterator::Read() 从 mysql.table_stats 表中读取 t1 表的统计信息。
information_schema.tables 视图会从 5 个基表（base table）中读取数据，执行流程会嵌套调用 NestedLoopIterator::Read()，共 5 层，以实现嵌套循环连接，为了简洁，这里只保留了 1 层。
NestedLoopIterator::Read() 从 information_schema.tables 视图的 5 个基表各读取一条对应的记录，并从中抽取客户端需要的字段，合并成为一条记录，用于发送给客户端。
MySQL 中实际只有抽取字段的过程，没有合并成为一条记录的过程，只是为了方便理解，才引入了合并这一描述。
不过，最终发送给客户端的记录的各个字段，不一定取自 5 个基表中读取的记录。
因为，从其中一个基表（mysql.table_stats）读取的 t1 表的统计信息，带有过期逻辑，如果统计信息过期了，会触发从 InnoDB 获取 t1 表的最新统计信息，替换掉从 mysql.table_stats 中读取到的相应字段，用于发送给客户端。
information_schema.tables 视图定义中，table_rows 是从基表 mysql.table_stats 读取的第 1 个字段，所以，发送 table_rows 字段值给客户端的过程中，会调用 is_persistent_statistics_expired() 判断 mysql.table_stats 中持久化的 t1 表的统计信息是否过期。
// sql/dd/info_schema/table_stats.cc// 为了方便理解，以 t1 表为例，// 介绍判断持久化统计信息是否过期的逻辑inline bool is_persistent_statistics_expired(THD *thd, const ulonglong &cached_timestamp) {// Consider it as expired if timestamp or timeout is ZERO.// !cached_timestamp = true，// 表示 t1 表的统计信息从来没有持久化过// !information_schema_stats_expiry = true，// 表示不需要持久化任何表的统计信息if (!cached_timestamp || !thd->variables.information_schema_stats_expiry)return true;// Convert longlong time to MYSQL_TIME format// cached_timestamp 表示上次持久化// t1 表统计信息的时间，// 对应 mysql.table_stats// 表的 cached_time 字段，// 变量值的格式为 20230619063657// 这里会从 cached_timestamp 中抽取// 年、月、日、时、分、秒，// 分别保存到 cached_mysql_time 对象的相应属性中MYSQL_TIME cached_mysql_time;my_longlong_to_datetime_with_warn(cached_timestamp, &cached_mysql_time,MYF(0));/*Convert MYSQL_TIME to epoc second according to local time_zone ascached_timestamp value is with local time_zone*/my_time_t cached_epoc_secs;bool not_used;// 上次持久化 t1 表的时间，转换为时间戳cached_epoc_secs =thd->variables.time_zone->TIME_to_gmt_sec(&cached_mysql_time, ¬_used);// 当前 SQL 开始执行的时间戳// 在 dispatch_command() 中赋值long curtime = thd->query_start_in_secs();ulonglong time_diff = curtime - static_cast(cached_epoc_secs);// 当前 SQL 开始执行的时间戳// - 上一次持久化 t1 表的时间戳// 是否大于系统变量 information_schema_stats_expiry 的值return (time_diff > thd->variables.information_schema_stats_expiry);}is_persistent_statistics_expired() 有 3 个判断条件：
条件 1：!cached_timestamp = true，说明 t1 表的统计信息从来没有持久化过，接下来需要从 InnoDB 获取 t1 表的最新统计信息，用于持久化和返回给客户端。
条件 2：!thd->variables.information_schema_stats_expiry = true，说明系统变量 information_schema_stats_expiry 的值为 0，表示不需要持久化任何表（当然包含 t1 表）的统计信息，接下来需要从 InnoDB 获取 t1 表的最新统计信息，用于返回给客户端。
条件 3：time_diff > thd->variables.information_schema_stats_expiry，这是 return 语句中的判断条件。
如果此条件值为 true，说明当前 SQL 的开始执行时间减去上一次持久化 t1 表统计信息的时间，大于系统变量 information_schema_stats_expiry 的值，说明之前持久化的 t1 表统计信息已经过期，接下来需要从 InnoDB 获取 t1 表的最新统计信息，用于持久化和返回给客户端。
对于 t1 表，不管上面 3 个条件中哪一个成立，is_persistent_statistics_expired() 都会返回 true。
接下来，Table_statistics::read_stat() 都会调用 Table_statistics::read_stat_from_SE() 从 InnoDB 获取 t1 表的最新统计信息。
// sql/dd/info_schema/table_stats.cc// 为了方便理解，同样以 t1 表为例// 代码中 table_name_ptr 对应的表就是 t1ulonglong Table_statistics::read_stat_from_SE(...) {...if (error == 0) {...if ...// 调用 innobase_get_table_statistics()// 从 InnoDB 获取 t1 表的统计信息else if (!hton->get_table_statistics(schema_name_ptr.ptr(),table_name_ptr.ptr(),se_private_id,*ts_se_private_data_obj.get(),*tbl_se_private_data_obj.get(),HA_STATUS_VARIABLE | HA_STATUS_TIME |HA_STATUS_VARIABLE_EXTRA | HA_STATUS_AUTO,&ha_stat)) {error = 0;}...}// Cache and return the statisticsif (error == 0) {if (stype != enum_table_stats_type::INDEX_COLUMN_CARDINALITY) {cache_stats_in_mem(schema_name_ptr, table_name_ptr, ha_stat);...// 调用 can_persist_I_S_dynamic_statistics()// 判断是否要持久化 t1 表的统计信息// 如果需要持久化，// 则调用 persist_i_s_table_stats()// 把 t1 表的最新统计信息// 保存到 mysql.table_stats 表中if (can_persist_I_S_dynamic_statistics(...) &&persist_i_s_table_stats(...)) {error = -1;} else// 持久化成功之后，从 ha_stat 中读取// stype 对应的字段值返回// 对于 SELECT * FROM information_schema.tables// stype 的值为// enum_table_stats_type::TABLE_ROWSreturn_value = get_stat(ha_stat, stype);}...}...}Table_statistics::read_stat_from_SE() 先调用 hton->get_table_statistics() 从存储引擎获取 t1 表的统计信息，对于 InnoDB，对应的方法为 innobase_get_table_statistics()。
获取 t1 表的统计信息之后，先调用 can_persist_I_S_dynamic_statistics() 判断是否需要持久化表的统计信息到 mysql.table_stats 中。
// sql/dd/info_schema/table_stats.cc// 为了方便阅读，以下代码的格式被修改过了inline bool can_persist_I_S_dynamic_statistics(...) { handlerton *ddse = ha_resolve_by_legacy_type(thd, DB_TYPE_INNODB); if (ddse == nullptr || ddse->is_dict_readonly()) return false; return (/* 1 */ thd->variables.information_schema_stats_expiry && /* 2 */ !thd->variables.transaction_read_only && /* 3 */ !super_read_only && /* 4 */ !thd->in_sub_stmt && /* 5 */ !read_only && /* 6 */ !partition_name && /* 7 */ !thd->in_multi_stmt_transaction_mode() && /* 8 */ (strcmp(schema_name, "performance_schema") != 0));}return 语句中，所有判断条件的值都必须为true，t1 表的统计信息才会被持久化到mysql.table_stats中，这些条件的含义如下：
条件 1：thd->variables.information_schema_stats_expiry = true，表示系统变量 information_schema_stats_expiry 的值大于 0。
条件 2：!thd->variables.transaction_read_only = true，表示系统变量 transaction_read_only 的值为 false，MySQL 能够执行读写事务。
条件 3、5：!super_read_only = true，并且 !read_only = true，表示系统变量 super_read_only、read_only 的值都为 false，MySQL 没有被设置为只读模式。
条件 4：!thd->in_sub_stmt = true，表示当前执行的 SQL 不是触发器触发执行的、也不是存储过程中的 SQL。
条件 6：!partition_name = true，表示 t1 表不是分区表。
条件 7：!thd->in_multi_stmt_transaction_mode()，表示当前事务是自动提交事务，即一个事务只会执行一条 SQL。
条件 8：strcmp(schema_name, "performance_schema") != 0)，表示 t1 表的数据库名不是 performance_schema。
如果 Table_statistics::read_stat_from_SE() 调用 can_persist_I_S_dynamic_statistics() 得到的返回值为 true，说明需要持久化 t1 表的统计信息，调用 persist_i_s_table_stats() 执行持久化操作。
// sql/dd/info_schema/table_stats.ccstatic bool persist_i_s_table_stats(...) {// Create a object to be stored.std::unique_ptr ts_obj(dd::create_object());setup_table_stats_record(thd, ts_obj.get(),dd::String_type(schema_name_ptr.ptr(), schema_name_ptr.length()),dd::String_type(table_name_ptr.ptr(), table_name_ptr.length()), stats,checksum, true, true);return store_statistics_record(thd, ts_obj.get());} persist_i_s_table_stats() 调用 setup_table_stats_record() 构造 Table_stat 对象，其中包含统计信息的各个字段。
然后，调用 store_statistics_record()，经过多级之后，最终会调用 Weak_object_impl_
主动持久化小节已经介绍过 setup_table_stats_record()、Weak_object_impl_
上一小节，我们以 t1 表为例，介绍了一个表的统计信息的持久化过程。
持久化的统计信息中包含 update_time，按理来说，既然已经持久化了，那它没有理由不靠谱对不对？
其实，update_time 之所以不靠谱，有 2 个原因：
原因 1：某个表的 update_time 发生变化之后，并不会马上被持久化。
需要执行 analyze table，才会触发主动持久化，而这个操作并不会经常执行。
从 information_schema.tables 视图读取表的信息（其中包含统计信息），这个操作也不一定会经常执行，退一步说，就算是监控场景下，会频繁查询这个视图，但也不会每次都触发被动持久化。
因为被动持久化还要受到系统变量 information_schema_stats_expiry 的控制，它的默认值是 86400s。
information_schema_stats_expiry 使用默认值的情况下，即使频繁查询 information_schema.tables 视图，一个表的统计信息，一天最多只会更新一次。
这里的统计信息，单指 mysql.table_stats 表中保存的统计信息。
原因 2：持久化之前，update_time 只位于内存中的 dict_table_t 对象中。
一旦 MySQL 挂了、服务器断电了，下次启动之后，所有表的 update_time 都丢了。
以及，如果打开的 InnoDB 表过多，缓存的 dict_table_t 对象数量达到上限（由系统变量 table_definition_cache 控制），导致 dict_table_t 对象被从 InnoDB 的缓存中移除，这些对象对应表的 update_time 也就丢了。
那么，既然都已经把表的统计信息持久化到 mysql.table_stats 中了，为什么不做的彻底一点，保证该表中的持久化信息和 InnoDB 内存中的信息一致呢？
根据代码中的实现逻辑来看，mysql.table_stats 中的持久化信息只是作为缓存使用，表中多数字段值都来源于其它持久化信息，而 update_time 字段值来源于内存中，这就决定了它的不靠谱。
我认为 update_time 的不靠谱行为是个 bug，给官方提了 bug，但是官方回复说这不是 bug。
感兴趣的读者可以了解一下，bug 链接如下：https://bugs.mysql.com/bug.php?id=111476
四、说说 mysql.table_stats 表默认情况下，我们是没有权限查看 mysql.table_stats 表的，因为这是 MySQL 内部使用的表。
但是，MySQL 也给我们留了个小门。
如果我们通过源码编译 Debug 包，并且告诉 MySQL 不检查数据字典表的权限，我们就能一睹 mysql.table_stats 表的芳容了。
关闭数据字典表的权限检查之前，看不到：
SELECT * FROM mysql.table_stats LIMIT 1\G(3554, "Access to data dictionary table"mysql.table_stats" is rejected.")关闭数据字典表的权限检查之后，看到了：
SET SESSION debug="+d,skip_dd_table_access_check";SELECT * FROM mysql.table_stats LIMIT 1\G[ 1. row ]schema_name | testtable_name | citytable_rows | 462avg_row_length | 177data_length | 81920max_data_length | 0index_length | 16384data_free | 0auto_increment | 3013checksum | cached_time | 2023-06-20 06:09:14为了方便介绍和理解，依然以 t1 表为例进行总结。
t1 表插入、更新、删除记录过程中，写 undo 日志之前，它的 dict_table_t 对象指针会被保存到 trx->mod_tables 集合中。
事务提交过程中，迭代 trx->mod_tables 集合（只包含 t1 表），把当前时间赋值给 t1 表 dict_table_t 对象的 update_time 属性，这就是 t1 表的最后修改时间。
如果执行 analyze table t1，会触发主动持久化，把 t1 表的统计信息持久化到 mysql.table_stats 表中。
如果通过 information_schema.tables 视图读取 t1 表的信息，其中的统计信息来源于 mysql.table_stats 表，从 mysql.table_stats 中读取 t1 表的统计信息之后，把 table_rows 字段值发送给客户端之前，会判断 t1 表的统计信息是否已过期。
如果已经过期，会触发被动持久化，把 t1 表的最新统计信息持久化到 mysql.table_stats 表中。
t1 表的统计信息中包含 update_time 字段，不管是主动还是被动持久化，t1 表 dict_table_t 对象的 update_time 属性值都会随着统计信息的持久化保存到 mysql.table_stats 表的 update_time 字段中。
虽然 t1 表 dict_table_t 对象的 update_time 属性值会持久化到 mysql.table_stats 表中，但是在持久化之前，update_time 只存在于内存中，一旦 MySQL 挂了、服务器断电了，或者 t1 表的 dict_table_t 对象被从 InnoDB 的缓存中移除了，未持久化的 update_time 属性值也就丢失了，这就是 update_time 不靠谱的原因。
本文转载自微信公众号「一树一溪」，可以通过以下二维码关注。转载本文请联系一树一溪公众号。