mysql-analyze table导致waiting for table flush

一、背景

一次普通的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解决的版本