Flush Tables 清空表缓存（table cache）和表定义缓存（table definition cache），强制关闭所有已打开表并丢弃元数据；它不清理查询缓存（query cache已移除）、InnoDB Buffer Pool或脏页。
Flush Tables 会清空哪些缓存？
FLUSH TABLES 命令并不清空查询缓存（query cache），而是清空 MySQL 层的 table cache（也叫表打开缓存）和关联的 table definition cache。它强制关闭所有已打开的表实例，并丢弃当前缓存的表元数据（如字段定义、索引结构等）。这直接影响后续查询是否能快速复用已有表描述，而非重新从磁盘或数据字典加载。
常见误解是认为 FLUSH TABLES 会“刷新查询结果”，但它对 SELECT 查询缓存毫无影响——因为 MySQL 8.0 已彻底移除 query cache，而 5.7 及更早版本中它由独立机制管理（FLUSH QUERY CACHE 才管那个）。
-
FLUSH TABLES触发的是表级句柄重建，不是 SQL 结果重算 - 它不涉及 InnoDB Buffer Pool，不会刷脏页或驱逐数据页
- 如果启用了
table_open_cache，该命令会让缓存“归零”，下一次访问表时需重新打开并计入缓存计数
为什么执行 FLUSH TABLES 后首次查询变慢？
执行 FLUSH TABLES 后，第一次对该表的 SELECT 查询明显变慢，核心原因是：MySQL 必须重新执行完整的表打开流程——读取 .frm（5.7）或 SDI（8.0）、解析表结构、构建 TABLE_SHARE 和会话独占的 TABLE 实例。这个过程涉及文件 I/O 和内存分配，在高并发或大表场景下尤为明显。
这不是“缓存没命中”的问题，而是“缓存被主动清空后重建”的代价。你可以通过以下方式验证：
- 执行
SHOW STATUS LIKE 'Opened_tables';，再执行FLUSH TABLES，之后查一次表，观察该值 +1 - 对比
SHOW STATUS LIKE 'Table_open_cache_hits';和Table_open_cache_misses，清空前后 miss 计数会上升 - 注意：这些状态变量只反映 MySQL 层的表打开行为，和 InnoDB 的
innodb_buffer_pool_reads无关
table_open_cache 和 table_definition_cache 如何影响命中？
table_open_cache 控制单次可缓存的“打开表实例”数量（每个连接对同一张表多次查询可能产生多个实例）；table_definition_cache 控制可缓存的“表定义”数量（全局唯一，不按连接计）。二者共同决定表元数据复用效率。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
当实际打开的表数超过 table_open_cache 时，MySQL 会按 LRU 策略淘汰旧实例，导致频繁重开；若 table_definition_cache 不足，则每次打开新表都需重新加载定义，哪怕表名相同。
- 典型配置建议：
table_open_cache = 2000，table_definition_cache = 1024（适用于数百张表的业务） - 过小的
table_open_cache会导致Opened_tables持续上涨，且Table_open_cache_misses占比升高 -
table_definition_cache设为 -1 表示自动计算（MySQL 8.0+ 推荐），但低于 400 会强制设为 400
FLUSH TABLES 在什么场景下真正有用？
它不是性能调优手段，而是运维/一致性保障动作。真实有价值的使用场景非常有限：
- 在主从复制中，执行
FLUSH TABLES WITH READ LOCK配合mysqldump获取一致快照（注意：8.0 中LOCK TABLES行为有变化） - 手动清理因异常导致的“卡住的表句柄”，比如某些连接崩溃后残留的未释放表引用
- 验证应用是否依赖隐式表缓存行为（例如 ORM 频繁
open/close同一表，暴露缓存不足问题）
别把它当成“清缓存提速”的操作——反而可能引发短时性能抖动。真正影响查询延迟的，是 innodb_buffer_pool_size 是否足够、索引设计是否合理，而不是 FLUSH TABLES 能干预的部分。
