MySQL 8.0生产环境打开表数超限，Flush Tables使用及优化咨询

如何降低打开表数？ #

• 先定位根源：用SHOW OPEN TABLES或performance_schema.table_open_cache_status排查哪些表被频繁打开，是否存在未关闭的连接持有表句柄，或是有一次性访问大量表的查询（比如多表JOIN、批量跨表操作）。
• 优化应用逻辑：
  • 替换大量短连接为连接池，复用现有连接，避免每次连接重复打开表。
  • 拆分复杂的多表查询，减少单次请求打开的表数量；避免不必要的跨表操作。
  • 配置合理的wait_timeout和interactive_timeout参数，让闲置连接自动断开，释放持有的表句柄。
• 调整MySQL参数：
  • 结合服务器内存情况，适度调大table_open_cache和table_definition_cache（比如先设为当前阈值的1.5倍，观察内存占用和告警情况，逐步调整）。
  • 确保table_open_cache_instances开启（MySQL 8.0默认开启），拆分表缓存到多个实例，减少锁竞争，提升缓存利用率。
• 清理冗余表：删除或归档长期未使用的表，减少需要维护的表总量。

执行带只读或读锁的Flush tables命令的影响？ #

• 数据丢失：完全不会导致数据丢失。FLUSH TABLES仅会关闭所有打开的表句柄、刷新表缓存，不会修改或删除任何数据；带读锁的FLUSH TABLES WITH READ LOCK (FTWRL)只是将所有表设为只读状态，阻止写入操作，已提交的数据不会丢失，解锁后写入功能立即恢复。
• 性能影响：
  • 普通FLUSH TABLES：执行时会遍历并关闭所有打开的表，期间会出现短暂的锁等待，高并发场景下会引发性能波动，比如查询会暂时等待表重新打开。
  • FLUSH TABLES WITH READ LOCK：执行后所有写入操作（INSERT/UPDATE/DELETE等）都会被阻塞，直到手动解锁，这会直接中断业务的写入能力，仅适用于全量备份等特殊场景，绝对不能在正常业务运行期间执行。

每日手动执行Flush tables是否属于生产环境最佳实践？ #

• 绝对不是。手动执行FLUSH TABLES只是临时应急手段，完全算不上最佳实践：
  • 频繁执行会导致表反复被打开和关闭，增加CPU、IO开销，反而可能降低整体性能。
  • 无法从根源解决表打开数过高的问题，只是临时释放缓存，治标不治本。
  • 高并发场景下执行极易引发性能抖动，影响业务稳定性。
• 正确做法是从根源入手，解决应用连接、查询逻辑、参数配置等核心问题，彻底消除表打开数过高的诱因。

内容的提问来源于stack exchange，提问作者Akhil Umap