清浅池塘线上环境出问题的时候，最怕的不是报错日志，而是“一切正常”的假象。服务没有崩，CPU也没跑满，但接口就是慢，从平均50ms一路飙到2秒，监控面板上SQL耗时和GC频率双双告警。这种时候，JVM调优和MySQL慢查询优化就成了两条并行的排查线，缺一不可。这篇博文不打算讲理论，也不写面试答案，就按我自己处理过的几起真实问题，把排查链路的完整过程、关键命令、执行计划怎么读、参数怎么定，一步步拆开讲清楚。适合已经写过一段时间Java后端、开始接触性能问题但还没系统动手过的同学。
调优这件事，最忌讳的是拿到问题就改参数。不管是JVM还是MySQL，参数永远只是最后一步，前面还有一长串定位工作要做。你把堆调大了，GC不频繁了，但如果根因是一条慢SQL拖垮了连接池，那折腾半天等于白做。所以这篇文章我会把两端串起来讲，核心就一句话：先找到真正的瓶颈，再谈优化。
1. JVM调优前必须搞清楚的排查链路：从报警到定位
1.1 先分清问题的类别，别急着动堆参数
很多新手一看到JVM调优，第一个念头就是“把-Xmx调大一点”。但JVM的问题是分门别类的，不同表现对应完全不同的处理方向。
我自己习惯把生产环境常见的JVM问题归成三类：
- CPU飙升类：表现为CPU使用率持续高位，但GC不一定频繁。这种问题大概率是业务代码里出现了死循环、大对象频繁创建、正则回溯、锁竞争，进程内某个线程一直处于Runnable状态。需要用jstack抓线程栈，找那个占用CPU高的线程在干什么。
- 高频GC类：表现为GC日志里Young GC非常频繁，或Full GC间隔越来越短。这种情况确实和堆内存设置有关，但更核心的问题是对象分配速率过高或者存在对象泄漏，光调堆是治标不治本。
- 内存溢出类：表现为抛出OutOfMemoryError，或者服务一段时间后内存占用持续上涨不回落。这类问题必须dump堆，分析对象的引用链，找到是谁持有这些对象不释放。
判断属于哪一类，第一步不是看任何调优文档，而是先看监控。如果你还没有接入APM或者监控系统，那先别管调优，把监控补上才是正事。
1.2 一套基础的诊断命令：jstat、jmap、jstack的正确用法
定位JVM问题，用得最多的是JDK自带的三个命令：jstat、jmap、jstack。它们各自解决不同层面的问题，很多人知道命令但不清楚什么时候用哪个，这里说一下我实际使用的判断路径。
jstat看GC趋势，这个命令负责回答“GC现在是什么状态”：
bash复制jstat -gcutil 12345 1000 10
上面这个命令的意思是，对PID为12345的进程，每隔1秒打印一次GC统计信息，总共打印10次。输出里的E代表Eden区使用比例，O代表老年代使用比例，FGC是Full GC次数，FGCT是Full GC总耗时。我一般会连续观察一小段，如果老年代占比持续在90%以上徘徊，说明对象晋升速度很快，要么是堆偏小，要么是存在大对象持续产生。
jmap看堆内存快照，这个命令负责回答“堆里到底装了什么”：
bash复制jmap -dump:format=b,file=heap.hprof 12345
生产环境执行这条命令要非常谨慎，因为dump大堆会触发一次较长的停顿，可能导致服务短暂不可用。我自己通常会用jmap -histo:live 12345先看一眼实例数量排行，确认是不是某个类的对象数量异常，如果确实有嫌疑再决定要不要做完整dump。
jstack抓线程快照，这个命令负责回答“线程现在卡在哪里”：
bash复制jstack 12345 > thread_dump.txt
线程快照抓下来之后，最简单的分析方式是抓三次，每次间隔10秒，对比线程栈有没有相同位置反复出现。如果每次都有大量线程阻塞在同一个锁或者同一个方法上，那问题就很明确了。
1.3 打开GC日志，拿到最直接的证据
线上环境默认是不打印GC日志的，这是很多团队排查JVM问题时最大的障碍——出了问题手里没有数据，全靠猜。我在所有Java服务启动参数里一定会加上GC日志配置，而且要加日期时间戳，方便后续按时间点跟业务链路对上。
JDK8及以下版本用：
bash复制-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log
JDK9及以上用新的参数风格：
bash复制-Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags
拿到GC日志后，重点看的不是某一行的格式，而是一个时间段内的节奏。比如正常情况下Young GC每几秒一次，每次耗时几十毫秒，这属于正常新对象分配导致的。但如果Young GC变成每秒好几次，每次要100毫秒以上，说明Eden区已经装不下这个量级的对象分配速率。再看Full GC，Full GC一般不应该频繁出现，JVM在年轻代和老年代都无法分配内存时才会触发Full GC，一旦Full GC间隔短于几十秒，服务卡顿就会直接反馈到接口延迟上。
我记得有一次线上服务每天下午高峰期接口都会出现一波毛刺，打开GC日志一看，Full GC每天固定在14点左右出现，每次停顿差不多2秒。顺着时间点一查，发现是定时任务在14点批量拉取数据，构造了一大批临时对象，一下把老年代打满了。后来把定时任务分批处理，问题就没了。
1.4 一次Full GC导致接口毛刺的完整定位过程
这里我展开一个典型的例子，方便大家理解上面这些命令是怎么串起来的。
现象是服务在业务高峰期出现周期性的接口延迟尖刺，从监控看，每5到10分钟就出现一次，持续时间大概两三秒。一开始怀疑是慢SQL，查了慢查询日志，发现确实有几条SQL在执行，但耗时也就几百毫秒，不至于造成两三秒的延迟。
于是去查GC日志，果然在延迟出现的时间点附近看到了Full GC记录。用jstat验证了一下，老年代使用率在Full GC前已经非常高，而且Young GC后有大对象直接进入老年代。最后用jmap看堆实例，发现业务查询结果集被封装成了非常大的对象，在Eden区放不下，直接被分配到老年代。老年代空间被这些大对象碎片化占满后，只能频繁触发Full GC。
整个过程回顾下来，真正要优化的不是堆大小，而是查询结果集的处理方式。后来加了一层分页限制和结果集裁剪，Full GC就从每几分钟一次降到了每天一两次。这个案例里，如果一开始就盲目把堆调大，虽然能暂时缓解，但对象本身的不合理设计依然存在，迟早还会出问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MySQL慢查询优化：先让执行计划说话
2.1 慢查询日志：优化工作的数据基础
MySQL慢查询优化跟JVM调优一样，第一步也是收集数据。没有慢查询日志，你就只能在出现问题的时候凭感觉猜是哪条SQL出了问题，这等于盲人摸象。
启动慢查询日志的配置并不复杂：
ini复制slow_query_log = ON
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = ON
这里的关键是long_query_time = 1表示超过1秒的SQL才记录。我见过很多团队把这个值设为10，基本等于没开，因为等一条SQL耗到10秒，用户体验早就崩了。生产环境建议先用1秒抓一轮，看看有哪些SQL超标，分析完之后再决定是否把阈值调到500毫秒。
慢查询日志文件如果多了，直接打开看会很痛苦，可以用mysqldumpslow工具聚合分析：
bash复制mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log
这个命令会按平均耗时排序，展示最耗时的前10条SQL，并且会把同类SQL（只是条件值不同）聚合在一起，方便快速定位高频慢SQL。
2.2 explain执行计划的阅读顺序，很多人第一步就错了
拿到慢SQL之后的例行操作是加explain看执行计划。但说实话，执行计划不是拿过来瞎看的，得有一个明确的阅读顺序。我一般是按这个顺序来看：
- id：id越大越先执行。多个id值说明是子查询或union，要顺着id从大到小去理解真正执行的先后顺序。
- select_type：重点关注是否有
DEPENDENT SUBQUERY或UNCACHEABLE SUBQUERY这类类型，出现说明子查询在性能上可能存在问题，MySQL要逐行去执行子查询。 - type：这是我最先关注的核心字段。从好到坏排列大致是
system、const、eq_ref、ref、range、index、ALL。如果看到ALL，说明这次查询是全表扫描，结合rows字段看扫描行数，基本就知道这条SQL慢在哪了。 - key：实际使用的索引，如果为NULL说明没有命中索引。
- rows：预估需要扫描的行数，这个值越大，查询代价越高。
- Extra：看到
Using filesort意味着排序没有用到索引，需要额外做一次文件排序；看到Using temporary说明用到了临时表。这两个都是优化方向的重要指示。
我见过不少同学在拿到执行计划后只看type是不是const，不看key和rows，结果明明走了索引，但预估扫描行数仍然很大，查询还是很慢。执行计划是一个整体，字段与字段之间互相印证，单独看一个值是看不全的。
2.3 索引失效的常见场景：用实际案例复现
索引失效是慢查询里面出现频率最高的原因之一。经常有开发说“我明明建了索引，为什么SQL还是慢”，然后去看执行计划，type全是ALL。这类问题大多数是SQL写法导致的索引失效，常见的几类场景如下。
函数包裹索引列。比如在创建时间上建了索引，但SQL写成了：
sql复制select * from order where DATE(create_time) = '2024-05-01'
这样的话，即使create_time列上有索引，MySQL也没法用，因为每一行都要先经过DATE()函数计算之后才能比较。正确的做法应该是：
sql复制select * from order where create_time >= '2024-05-01 00:00:00' and create_time < '2024-05-02 00:00:00'
隐式类型转换。这个更隐蔽，比如状态字段status在表里是varchar，但查询条件传的是数字：
sql复制select * from order where status = 1
MySQL会把字符串列转成数字进行比较，导致索引失效。修复方法也很简单，查询条件里加引号，或者干脆把字段类型改成整型。
不满足最左前缀原则。联合索引(user_id, create_time, status)建出来之后，查询条件是直接create_time > '2024-01-01'，那么第二个字段只用到了联合索引中的create_time，属于范围查询，后面的status列就没法走索引了。
LIKE模糊匹配前导通配符。like '%abc'这种写法，索引无法从字符串中间开始定位，MySQL只能做全表扫描。
想要验证是不是走对了索引，原则上来讲就是执行完explain之后，用key_len字段去确认实际用到的索引列。key_len越长，说明索引覆盖到的列越多。
2.4 排序、联合索引与覆盖索引：把优化做到查询之外
对于经常出现的排序慢问题，我建议优先考虑在索引上解决，因为MySQL的Using filesort在数据量大时非常消耗性能。比如查询是where user_id = ? order by create_time desc，那联合索引直接建(user_id, create_time)，排序就能沿着索引顺序完成，不需要再额外排序。
这里还要提一下覆盖索引这个思路。覆盖索引指的是查询需要的所有列都在索引里，MySQL不需要回表去查聚簇索引里的完整数据行。比如销售报表要统计每个用户的订单金额，如果索引是(user_id, order_amount)，那么
sql复制select user_id, sum(order_amount) from order group by user_id
这个过程可以直接在索引上完成，完全不需要回表。数据量大的时候，这个优化带来的性能提升非常可观。
但索引不是越多越好。每多一个索引，写入的时候就要多维护一棵B+树，插入变慢。索引设计的核心在于平衡：针对核心查询路径建立合理索引，而不是把所有查询条件都建一个索引。
3. 一个事故里同时出现GC频繁和慢SQL，真正的病因只有一个
3.1 故障现象：连接池被占满，线程卡死
有一次我处理过一个挺典型的案例，现象比单纯JVM毛刺或者单纯慢SQL都要更复杂。
某个核心接口在业务高峰时段突然大面积超时，监控面板上看到三个维度的异常：服务线程池活跃线程数跑满、JVM Full GC频次上升、数据库连接池活跃连接数也接近最大值。常规思路是分两个团队分别排查，一个看JVM，一个看数据库，但当时我总觉得这三者之间存在一条因果链，而不是三个独立故障。
把三组监控放在同一时间轴上看，就能发现先后顺序。先是数据库执行耗时开始上涨，接着连接池活跃连接数跟着上涨，一段时间之后才出现Full GC频次增加，最后是服务线程池跑满。
3.2 从线程栈到执行计划，一步步还原真实的因果链
当时抓了线程栈，发现大量业务线程阻塞在获取数据库连接的地方，等不到连接就一直在等待。接着看数据库连接池，空闲连接数已经是0。再看MySQL这边，进程并没有死，慢查询日志里出现了几条平时没见过的SQL，而且这几条SQL的执行计划都是全表扫描。
这时候因果链就浮出来了：几条SQL因为数据量增长走到了全表扫描，每条SQL的执行时间从几十毫秒变成了好几秒。一个请求虽然只会占一个连接，但SQL耗时长，连接就被长时间占用，后续请求进来排队等连接。连接池被打满之后，服务端的业务线程也全部卡在等待数据库连接上，没法处理新请求，接口直接超时。由于请求堆积，产生了大量等待中的线程和对象，JVM老年代被这些堆积的请求对象迅速填满，触发了Full GC，反过来又让服务更慢。
JVM和MySQL在这一刻不是两个独立的问题，而是一根链条上的两环。如果我当时先去调JVM堆大小，或者先加MySQL缓存，都没法真正解决问题，因为源头是那几条SQL的访问路径出了问题。
3.3 根因分析与修复：治标和治本要分前后
根因定位之后，修复方案就是我常说的“先治标，再治本”。
治标的第一件事不是在SQL上折腾，而是先把连接池和应用线程池的配置重新核对一遍，确保有合理的超时和拒绝策略，避免数据库卡住时整个应用彻底不可用。连接池参数里超时时间尤为重要，如果获取连接时的最大等待时间设置成无限，那数据库一旦出问题，服务会直接陷入不可恢复的线程阻塞。
治本就是处理那几条慢SQL。当时数据量已经到了一个临界点，建索引确实能解决，但我还确认了这些SQL是不是被频繁调用，最终对其中两个场景做了代码层面的改造，合并了查询次数。SQL执行时间降下来之后，连接池占用率立刻回落，Full GC也跟着消失了。
3.4 双向验证与后续防范：任何优化都要回到监控闭环
修完之后，我习惯把修复前后的监控数据和GC日志放在一起对比验证。修复前Full GC每隔几分钟一次，修复后降到一天两三次；修复前连接池活跃连接数长期在80%以上，修复后回落到30%左右。这个闭环很重要，不然你根本不知道修复到底有没有生效。
后续的防范措施主要有三块：慢查询日志持续开着，新增索引要人工review执行计划，关键接口要在监控里同时配置线程池和连接池的水位告警。很多时候故障不是一瞬间发生的，而是一条曲线慢慢爬坡，水位告警能让你在故障爆发前就介入处理。
4. 参数设置清单与文档不会写的保守原则
4.1 按场景分组的JVM参数参考
参数设置要按场景来，不同的业务类型对停顿的容忍度完全不同。我平时的配置思路大致如下：
| 场景 | 核心参数 | 说明 |
|---|---|---|
| 低延迟要求（在线交易） | -XX:+UseG1GC -XX:MaxGCPauseMillis=100 |
G1垃圾收集器适合大堆并且有停顿目标需求的场景 |
| 高吞吐（离线任务） | -XX:+UseParallelGC |
Parallel GC关注最大化吞吐，容忍出现较长时间的GC停顿 |
| 堆内存设置 | -Xms4g -Xmx4g |
初始堆和最大堆设为相等，避免运行时动态扩容带来的性能损耗 |
| GC日志 | -Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags |
生产环境必须开，这是排查问题的基础 |
-Xms和-Xmx设成一样大，是我一直在用的实践。不用等JVM启动后随着并发量逐步扩容，一次性分配到位，减少运行期的堆扩容开销。尽管有说法认为相等的设置浪费了扩容机制，但生产环境的稳定性比这点空间节省重要得多。
4.2 MySQL关键参数：改之前先想清楚影响面
MySQL参数不能照搬网上的调优文章，不同版本的默认值变化很大。我整理了几个在8.0版本下值得重点关注的参数：
| 参数 | 建议方向 | 说明 |
|---|---|---|
innodb_buffer_pool_size |
物理内存的60%-70% | InnoDB的缓存池，设置过小会导致频繁磁盘IO |
max_connections |
视连接池上限而定 | 默认151，需要结合应用连接池规模做整体规划 |
slow_query_log |
ON，阈值1秒 | 慢查询日志是SQL优化的第一手数据 |
tmp_table_size |
适当调大 | 避免排序分组时频繁落盘临时表 |
query_cache_type |
保持OFF | 8.0版本已移除Query Cache，依赖它不现实 |
innodb_buffer_pool_size是InnoDB引擎的性能核心，它决定多少数据页可以常驻内存。如果这个值过小，数据页会被频繁换入换出，磁盘IO成为瓶颈。但设得过大也不行，要留给操作系统和文件系统一部分缓冲空间，否则其他组件内存不足会引发系统级别的资源争抢。
4.3 有些参数不建议乱调，这些坑我踩过
参数表看着简单，实际上有不少反直觉的坑，我一个个说一下。
第一，JVM的-Xmx不是越大越好。堆设得过大，GC每次回收的范围变大，单次停顿时间会明显拉长。尤其是使用Parallel GC时，堆过大会让Full GC变成秒级甚至几十秒级别的事件，谁也扛不住。正确的做法是结合业务实际对象生命周期来做压测验证，堆大小不是数字越大越快。
第二，MySQL的max_connections调大要配套看系统的文件句柄限制。连接数只是表象，每个连接都有对应的文件描述符和内存占用，盲目调到几千很容易直接打到系统资源上限。
第三，MySQL 8.0彻底移除了Query Cache，这个功能在5.7及之前默认关闭本身就有它的道理。并发场景下Query Cache的全局锁竞争反而会成为瓶颈，不要指望靠它提升查询性能。
第四，关于索引，我不是很主张通过force index去强行干预执行计划。force index这类手段内部验证可以，线上不建议长期使用，因为索引统计信息会随着MySQL的analyze更新而变化，强制指定的索引未必在所有阶段都是最优选择。优化器选错索引的时候，我的选择是调整SQL写法或者重建统计信息，而不是做强制干预。
4.4 我的一些实际操作体会：单变量原则和灰度心态
最后聊一点工作方法。调优最怕的是同时动多个参数，最后问题解决了，但根本说不清楚是哪个参数起了作用。
我自己的原则是：一次只改一个变量。
比如先观察一段时间确认基线数据，然后调整一个参数，观察至少一天以上的监控数据和GC日志，确认没有副作用后再进行下一个调整。排队压测的时候也要有灰度心态，先在一台机器上验证，稳定了再全量发布。JVM参数里连-XX:+PrintGCDetails这种看似无害的日志参数，印多了都可能对性能有一点点影响，更不用说改堆大小和GC类型了。
调优文档和视频确实很多，但真正解决问题靠的还是自己手里那台机器的监控数据。把这些基础的数据收齐了，分析思路理顺了，不管是JVM还是MySQL的问题，你在面对的时候心里会有底得多。
5. 一次完整的线上问题复盘：从慢SQL到GC频繁再到连接池耗尽
5.1 事件回顾：业务高峰期接口超时率骤升
上面几个章节的思路都串起来看一遍，我用一个复盘案例来说明它们如何协作。
某个周五下午的流量高峰，业务方反馈部分用户出现订单查询超时。监控平台很快弹出几条告警，包括接口P99延迟超过3秒、MySQL活跃连接数接近上限、应用GC暂停时间超标。三个告警同时出现，乍一看毫无头绪，但其实已经在提示最长链路里存在一个核心瓶颈。
5.2 定位过程：三个环节的逐项排除
开始排查时先把JVM堆快照和GC日志拉出来看了一眼，发现Full GC每两分钟一次，每次暂停约1.8秒。老年代占用率很高，但并不是内存泄漏那种持续上涨无法回收的曲线，每次Full GC之后能回到40%左右。这说明不是内存泄漏，而是瞬时对象压力太大。
于是去看MySQL。慢查询日志里发现一条绑定商品信息的SQL，扫描行数500万左右，等于全表扫。这条SQL每天执行次数并不高，但一下把连接池里的连接全部占住，后续请求只能排队。
这两个信息合在一起，事情的经过就还原出来了：慢SQL执行时间太长，连接池连接被占满，新请求一直等待数据库连接，请求线程越积越多，每个请求都在构造对象等待响应，老年代被这些等待中的请求对象填满，触发频繁Full GC。CPU和GC又在争夺时间片，服务整体变慢，最后表现为接口大面积超时。
5.3 修复动作与前后对比
当时做的修复分三步。先把慢SQL涉及的查询条件重新设计了索引，让扫描行数从500万直接降到几百行。然后把服务获取连接的超时时间从默认值改成3秒，避免数据库不可用的时候无限等待。最后给连接池加了监控告警，水位超过80%就通知。
修复之后观察了三天，接口P99从3秒回到200毫秒以内，Full GC从每两分钟一次降到一天不到一次，连接池活跃连接数稳定在30%左右。慢SQL那条从500万行扫描到几百行，执行时间从2.3秒降到15毫秒。
5.4 复盘结论：性能问题是链路问题，不是单点问题
这个案例给我最大的感受是，性能问题是链路问题，不是单点问题。慢SQL和GC看起来一个属于数据库，一个属于应用，但在一个完整的请求链路里，它们互为因果，一个环节出问题会顺着链路传导到另一个环节。如果你只盯着眼前看的领域去排查，很容易陷入“双方都没查出问题但业务确实在报障”的局面。
我现在的做法是，任何性能告警出现后，先拉出请求链路上的全量数据，把应用线程状态、GC日志、数据库执行计划放在同一时间轴上看，谁先发生，谁后发生，因果链自然就清楚了。
最后想说的话
这篇文章里的每个案例都是我在实际项目中跑过的排查路径，从开局工具到参数选型，再到最后的复盘和监控闭环，每一步都能直接在你自己负责的服务上验证。JVM调优和MySQL慢查询优化这两件事，网上从来不缺方案，缺的是把两端串起来分析问题的整体视角。我个人体会最深的其实是两点，一是日志和监控必须提前埋好，否则故障来了你只能对着空转的监控面板干瞪眼；二是参数永远是在数据面前低头的，基线数据没采集完之前，不要改任何配置。先把这两点养成习惯，再按文章里的路径去练几次，性能问题的处理能力自然就长在你自己身上了。