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 健康度。
