17370845950

MySQL自身不使用JVM，不会发生Full GC；所谓“MySQL的Full GC”实为Java应用层（如JDBC连接池、监控代理、ORM框架）内存压力过大所致，需分层定位优化。

避免 MySQL 频繁 Full GC，核心不是调大堆内存，而是减少 Java 层（如 JDBC 连接池、监控代理、ORM 框架）的内存压力，并确保 MySQL 自身配置合理、不把压力转嫁给 JVM。

确认 Full GC 真正来源

MySQL 服务进程本身是 C/C++ 编写的，**不使用 JVM，不会发生 Full GC**。所谓“MySQL 的 Full GC”，通常指以下场景：

• 应用服务（如 Spring Boot）通过 JDBC 访问 MySQL，JVM 堆内存不足，触发频繁 Full GC；
• MySQL 被套在 Java 容器中运行（极少见，如某些嵌入式测试库）；
• 监控工具（如 Prometheus + jmx_exporter）、APM（如 SkyWalking agent）采集 MySQL 指标时自身 GC 异常。

先用 jstat -gc 或 Arthas 查看 GC 日志，确认是哪个 Java 进程在 GC，再针对性优化。

优化 JDBC 与连接池配置

大量短连接、超大结果集、未关闭 ResultSet，都会导致 JVM 堆内存快速堆积：

• 设置连接池最大活跃数（如 HikariCP 的 maximumPoolSize）≤ 数据库 max_connections 的 70%，避免连接耗尽或空闲连接长期占用堆；
• 查询大表时禁用 fetchSize = Integer.MIN_VALUE（流式读取），改用分页或限制 LIMIT；
• 显式关闭 ResultSet、Statement、Connection（推荐 try-with-resources）；
• 避免在 SQL 中用 SELECT *，只查必需字段，减少对象封装开销。

调整 MySQL 服务端内存参数（间接降低 JVM 压力）

MySQL 配置不当会导致慢查询、锁等待、临时表膨胀，迫使应用层重试/缓存/聚合，加重 JVM 负担：

• innodb_buffer_pool_size：设为物理内存的 50%–75%（专用 DB 服务器），确保热数据常驻内存，减少磁盘 IO 和查询延迟；
• sort_buffer_size、join_buffer_size：按需调小（如 256K–2M），避免为每个连接分配过大线程私有内存；
• tmp_table_size 和 max_heap_table_size：保持一致（如 64M），防止隐式磁盘临时表，但也不宜过大，避免内存浪费；
• 开启 slow_query_log，定期分析并优化执行计划含 Using filesort 或 Using temporary 的语句。

检查 Java 应用层常见陷阱

很多“MySQL 导致 Full GC”实为应用代码问题：

• 将全量查询结果（如百万级 List）塞进静态 Map 或缓存，长期不清理；
• 用 new String(bytes) 处理大字段（如 BLOB），触发多次字符串拷贝和 char[] 分配；
• 日志框架（如 Logback）配置了 %ex 打印完整异常栈，而 MySQL 连接超时异常携带了大量连接上下文对象；
• MyBatis 的 resultMap 定义了过多嵌套对象或未启用 autoMappingBehavior=NONE，导致反射创建大量中间对象。

不复杂但容易忽略：先定位 GC 主体，再分层排查——数据库配置影响查询效率，查询效率影响应用内存行为，应用行为决定 JVM 健康度。