Information_Schema.tables 视图中，表的最后修改时间靠谱吗？-51CTO.COM

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.tables
WHERE table_schema = 'test'
AND table_name = 't1'\G
TABLE_CATALOG   | def
TABLE_SCHEMA    | test
TABLE_NAME      | t1
TABLE_TYPE      | BASE TABLE
ENGINE          | InnoDB
VERSION         | 10
ROW_FORMAT      | Dynamic
TABLE_ROWS      | 3
AVG_ROW_LENGTH  | 5461
DATA_LENGTH     | 16384
MAX_DATA_LENGTH | 0
INDEX_LENGTH    | 0
DATA_FREE       | 6291456
AUTO_INCREMENT  | 4
CREATE_TIME     | 2023-06-18 15:49:17
UPDATE_TIME     | 2023-06-18 15:50:37
CHECK_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.cc
dberr_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<
dict_table_t *,
std::less<dict_table_t *>,
ut::allocator<dict_table_t *>>
trx_mod_tables_t;
// storage/innobase/include/trx0trx.h
struct trx_t {
...
trx_mod_tables_t mod_tables;
...
}

集合中保存的是 InnoDB 表对象的指针 dict_table_t *，dict_table_t 结构体的 update_time 属性用于保存表的最后修改时间：

// storage/innobase/include/dict0mem.h
struct dict_table_t {
...
/** Timestamp of the last modification of this table. */
// 为了方便阅读，这个定义经过了格式化
std::atomic<
std::chrono::system_clock::time_point>
update_time;
...
}

trx_undo_report_row_operation() 只会标记表的数据发生了变化，不会修改表的 dict_table_t 对象的 update_time 属性。

2、确定变化时间

// storage/innobase/trx/trx0trx.cc
dberr_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.cc
static 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 <table_name> 执行过程中，会把表的统计信息持久化到 mysql.table_stats 表中，这些统计信息里就包含了 dict_table_t 对象的 update_time 属性。

我们把这种场景称为主动持久化，部分堆栈如下：

| > 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<dd::Table_stat>() sql/dd/impl/cache/dictionary_client.cc:2595
| + - x = | > Storage_adapter::store<dd::Table_stat>() 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.cc
int 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.cc
bool update_table_stats(THD *thd, Table_ref *table) {
// Update the object properties
HA_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<Table_stat> ts_obj(create_object<Table_stat>());
// 为 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_statistics

analyze 过程中，ha_innobase::analyze()、ha_innobase::info() 都会调用 ha_innobase::info_low()，看起来是重复调用了，不过，这两次调用的参数值不完全一样，我们就不深究了。

create_object<Table_stat>() 构造一个空的 Table_stat 对象，setup_table_stats_record() 为该对象的各属性赋值。

inline void setup_table_stats_record(THD *thd, dd::Table_stat *obj, ...) {
...
// stats 的类型为 ha_statistics
if (stats.update_time) {
// obj 的类型为 Table_stat
obj->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_statistics
ha_statistics -> Table_stat

setup_table_stats_record() 为 Table_stat 对象各属性赋值完成之后，update_table_stats() 接着调用 thd->dd_client()->store()，经过多级之后，调用 Weak_object_impl_<use_pfs>::store() 执行持久化操作。

// sql/dd/impl/types/weak_object_impl.cc
// 为了方便介绍，我们以 t1 表为例
// 介绍表的统计信息持久化过程
template <bool use_pfs>
bool Weak_object_impl_<use_pfs>::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<Object_key> obj_key(this->create_primary_key());
    ...
    // 
    // 从 mysql.table_stats 表中
    // 查询之前持久化的 t1 表的统计信息
    std::unique_ptr<Raw_record> 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<Raw_new_record> 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_<use_pfs>::store() 的代码逻辑。

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_statistics
ha_statistics -> Table_stat
Table_stat -> Raw_record

// sql/dd/impl/types/table_stat_impl.cc
bool 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_<use_pfs>::store() 接下来调用 r->update() 把 t1 表的最新统计信息更新到 mysql.table_stats 中，完成持久化操作。

如果 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.tables
WHERE table_schema = 'test' AND
table_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<dd::Table_stat>() sql/dd/info_schema/table_stats.cc:147
| + - x = | + - x = | + - x = > Dictionary_client::store<dd::Table_stat>() sql/dd/impl/cache/dictionary_client.cc:2595
| + - x = | + - x = | + - x = | > Storage_adapter::store<dd::Table_stat>() 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 as
cached_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 对应的表就是 t1
ulonglong 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 statistics
if (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_ROWS
return_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.cc
static bool persist_i_s_table_stats(...) {
// Create a object to be stored.
std::unique_ptr<dd::Table_stat> ts_obj(dd::create_object<dd::Table_stat>());
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_<use_pfs>::store() 方法执行持久化操作。

主动持久化小节已经介绍过 setup_table_stats_record()、Weak_object_impl_<use_pfs>::store() 这 2 个方法的代码，这里就不再重复了。

三、为什么不靠谱

上一小节，我们以 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     | test
table_name      | city
table_rows      | 462
avg_row_length  | 177
data_length     | 81920
max_data_length | 0
index_length    | 16384
data_free       | 0
auto_increment  | 3013
checksum        | 
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 不靠谱的原因。

本文转载自微信公众号「一树一溪」，可以通过以下二维码关注。转载本文请联系一树一溪公众号。