当前位置：首页 > news >正文

mysql-analyze table导致waiting for table flush

news 来源：原创 2025/6/8 18:10:31

一、背景

一次普通的analyze table操作却锁住了后续的查询

mysql> select sleep(100) from a;

analyze table a;

mysql> select * from a;


# 遇到这种情况就需要查询阻塞的sql，然后kill掉，或者也可以等待
68050436 | test          | 2025-02-26 11:52:40 | select sleep(100) from a

二、源码分析

这是percona解决这个问题所涉及的改动，增加了一个skip_flush 的布尔常量

@@ -906,6 +906,9 @@ static bool mysql_admin_table(THD* thd, TABLE_LIST* tables,
    }
    if (table->table)
    {

+      const bool skip_flush=
+        (operator_func == &handler::ha_analyze)
+        && (table->table->file->ha_table_flags() & HA_ONLINE_ANALYZE);
      if (table->table->s->tmp_table)
      {
        /* 
@@ -915,7 +918,7 @@ static bool mysql_admin_table(THD* thd, TABLE_LIST* tables,
- 原逻辑：只要需要修改表或发生致命错误，就移除表缓存
- 新逻辑：当且仅当（不需要跳过刷新 且 需要修改表）或发生致命错误时，才移除表缓存
- 保留了致命错误时的强制刷新逻辑
 */
        if (open_for_modify && !open_error)
          table->table->file->info(HA_STATUS_CONST);
      }
-      else if (open_for_modify || fatal_error)
+      else if ((!skip_flush && open_for_modify) || fatal_error)
      {
        tdc_remove_table(thd, TDC_RT_REMOVE_UNUSED,
                         table->db, table->table_name, FALSE);

下面是当前的完整代码

// 当表对象存在时
if (table->table)  
{
    // 判断是否需要跳过缓存刷新（在线分析且引擎支持在线分析时跳过）
    const bool skip_flush = 
        (operator_func == &handler::ha_analyze) &&
        (table->table->file->ha_table_flags() & HA_ONLINE_ANALYZE);

    // 处理临时表逻辑
    if (table->table->s->tmp_table) 
    {
        /*
          如果表未成功打开，则不尝试获取状态信息
          (修复Bug#47633)
        */
        if (open_for_modify && !open_error)
            table->table->file->info(HA_STATUS_CONST); // 获取存储引擎状态信息
    }
    // 非临时表且满足以下条件时
    else if ((!skip_flush && open_for_modify) || fatal_error) 
    {
        // 从表定义缓存中移除该表（非强制模式）
        tdc_remove_table(thd, TDC_RT_REMOVE_UNUSED,
                        table->db, table->table_name, FALSE);
        
        /*
          可能有修改操作发生，因此需要
          使查询缓存失效
        */
        table->table = 0;                        // 重置表指针（用于查询缓存失效）
        query_cache.invalidate(thd, table, FALSE); // 使该表的查询缓存失效
    }
    else 
    {
        /*
          当执行 ALTER TABLE 的分区管理操作时
          （如 ANALYZE/CHECK PARTITION）
          重置需要处理的分区状态
        */
        if (table->table->part_info &&
            lex->alter_info.flags & Alter_info::ALTER_ADMIN_PARTITION) 
        {
            set_all_part_state(table->table->part_info, PART_NORMAL); // 将所有分区状态设为正常
        }
    }
}

/* 错误处理路径：管理命令执行失败时 */
if (thd->transaction_rollback_request) 
{
    /*
      罕见情况：存储引擎请求事务回滚
      （例如发生死锁时），执行回滚操作
    */
    if (trans_rollback_stmt(thd) || trans_rollback_implicit(thd))
        goto err; // 跳转到错误处理
}
else 
{
    // 正常提交事务
    if (trans_commit_stmt(thd) || trans_commit_implicit(thd))
        goto err; // 提交失败则跳转错误处理
}

// 关闭线程相关的表对象
close_thread_tables(thd);  
// 释放事务相关的元数据锁
thd->mdl_context.release_transactional_locks();

三、percona解释

发生这种情况的原因是，在修复之前， ANALYZE TABLE 的工作方式如下：

打开表统计信息：允许并发 DML 操作（INSERT / UPDATE / DELETE / SELECT ）
更新表统计信息：允许并发 DML 操作
更新完成
使表定义缓存中的表条目无效：禁止并发 DML 操作
4.1. 这里发生的事情是ANALYZE TABLE 将当前打开的表共享实例标记为无效。这不会影响正在运行的查询：它们将照常完成。但所有传入查询都将无法启动，直到它们可以重新打开表共享实例。并且这在所有当前正在运行的查询完成之前不会发生。
使查询缓存无效：禁止并发 DML 操作

最后两个操作通常很快，但如果另一个查询触及表共享实例或获取查询缓存互斥锁，则它们无法完成。反过来，它也无法允许传入查询启动。

但是ANALYZE TABLE 修改的是表统计信息，而不是表定义！实际上，它不会以任何方式影响已经运行的查询。如果查询在ANALYZE TABLE 完成更新统计信息之前启动，则它使用旧统计信息。ANALYZE TABLE不会影响表中的数据。因此，查询缓存中的旧条目仍然是正确的。它没有更改表的定义。因此，无需将其从表定义缓存中删除。因此，我们避免了上面的操作 4 和 5。

对lp:1704195的修复（迁移至PS-2503）删除了这些额外的更新以及它们所需的锁，并使ANALYZE TABLE 始终能够在繁忙的生产环境中安全运行。

参考文章：
八怪大佬的文章
percona解决的版本
mysql官方bug记录地址
percona解决的详细信息
percona解决的版本