JVM调优与MySQL慢查询优化实战：从Full GC到索引设计的完整链路

你是不是也遇到过这种情况：明明代码逻辑看起来没问题，可一到业务高峰期，接口就慢得像老牛拉车，CPU飙到 100%，数据库连接池被打满，偶尔还来一次 Full GC 把服务卡死几秒。新手第一反应是加机器、加缓存，但资深一点的工程师都知道，问题大概率出在两个地方：JVM 的内存管理，和 SQL 的执行效率。这次就把这两块放一起聊透，用一次线上订单导出功能的真实调优过程，把 JVM 调优实操和 MySQL 慢查询优化的完整链路走一遍。

这次的内容适合谁？刚接触性能优化的后端开发、准备 JVM 和 MySQL 面试的候选人，以及那些被线上性能问题折磨得睡不着觉的运维和架构师。我会把思路、参数、排查命令、SQL 改写细节全部摊开来讲，不藏着掖着，保证你读完能直接用到自己的项目里。

1. 内容整体设计与思路拆解

1.1 这次调优的背景：一个订单导出功能引发的连锁反应

当时业务方反馈了一个问题：运营后台的订单导出功能，导出的数据量一旦超过 5 万条，页面就会一直转圈，等上两三分钟才有响应，偶尔直接报 504 超时。监控平台上看到的现象更直观——应用服务器 CPU 使用率接近 100%，MySQL 的 CPU 也居高不下，慢查询日志里每几分钟就多一条执行时间 10 秒以上的 SQL。

很多人在这种时候容易陷入误区，一上来就想着改代码、加并发、上消息队列。我的建议是：先把现象和数据收集齐，用证据说话。当时的处理顺序是这样的：先看 JVM 的 GC 情况和堆内存占用，再看 MySQL 的慢查询日志和执行计划，两头并进，最终发现两个问题其实是互相放大的——JVM 频繁 Full GC 导致服务响应变慢，慢 SQL 长期占用数据库连接又加剧了应用侧的线程阻塞，两者形成了恶性循环。

1.2 为什么把 JVM 和 MySQL 放在一起调优

很多项目组习惯把应用调优和数据库调优分成两个团队来做，JVM 的问题就找中间件团队，SQL 的问题就扔给 DBA。但实际生产环境中，JVM 和 MySQL 是同一套请求链路上的两个环节，任何一个环节出问题，都会拖累整体性能。

拿这次的订单导出举例：应用层一次性从数据库查出 5 万条记录，这些数据要放进 List 里，再通过 POI 写入 Excel 文件。这个过程中，JVM 堆内存要承载大量订单对象，同时数据库要执行大范围查询和排序。如果只优化 JVM 而不优化 SQL，查询 10 秒的超时时间照样让前端等不起；如果只优化 SQL 而不优化 JVM，那瞬间加载进内存的 5 万条订单对象又会让老年代直接爆掉，触发频繁 Full GC。两个必须配合着调，才能达到"数据库快点出数据、JVM 稳稳装下数据"的理想状态。

1.3 方案选型的底层逻辑：先止损，再优化，最后预防

性能优化的黄金法则是：先止损，再优化，最后预防。止损的意思是先把线上故障压下去，比如先把导出功能的超时时间调大、限制单次导出数量，让系统先恢复正常；优化是我的主要工作，就是本文要讲的这两条主线；预防则是在优化完成后，搭建监控和告警机制，避免问题再次发生。

这套逻辑同样适用于技术选型。JVM 的选择上，当时服务用的 JDK 8，默认的垃圾收集器是 Parallel Scavenge + Parallel Old，这套组合更看重吞吐量，对响应时间不敏感。但订单导出属于典型的 IO 密集 + 大对象分配场景，我更倾向于使用 G1 收集器，它能更好地控制停顿时间。MySQL 侧的选择则是从 InnoDB 存储引擎的特性出发，利用覆盖索引和延迟关联来减少回表次数。这些选择都不是拍脑袋决定的，背后都有明确的依据，后续章节会逐一展开。

2. JVM 调优核心细节与实操要点

2.1 先把 JVM 内存模型和堆结构摸清楚

聊 JVM 调优，第一个绕不开的就是内存模型。很多新手一听到 JVM 内存模型就头大，其实可以把它理解成一家餐厅的厨房——堆内存是食材仓库，栈是厨师的操作台，方法区是挂在墙上的菜谱。你往仓库里堆再多的食材，操作台太小，菜还是做不快。JVM 调优的本质，就是给仓库和操作台分配合适的大小，并保证厨师的出菜节奏稳定。

具体到这次场景，重点在堆内存的内部结构。堆内存分三块：新生代（Young）、老年代（Old）和元空间（Metaspace）。新生代里又细分为 Eden 区和两个 Survivor 区，比例默认是 8:1:1。新创建的对象都先进 Eden 区，Eden 满了触发 Minor GC，存活的对象被挪到 Survivor 区。对象每熬过一次 Minor GC，年龄就加 1，默认到 15 岁还活着，就晋升到老年代。老年代存放的是生命周期长的对象，满了之后触发 Major GC / Full GC，而 Full GC 是最伤性能的，因为它要回收整个堆。

我建议你在动手调参之前，先做一件非常关键的事——用 jmap 或者 MAT 查看堆内存里的对象分布。当时我用 jmap -dump 导出了线上环境的堆转储文件，用 MAT（Memory Analyzer Tool）一分析，发现订单对象占了老年代将近 40% 的空间，而且大量订单对象的 byte[] 字段直接把内存顶得满满的。这就解释为什么导出功能一运行，老年代就迅速膨胀、Full GC 的频率直线上升——因为一次性加载 5 万条订单到内存里，还都是大对象，新生代的 Survivor 区根本装不下，直接晋升到了老年代。

2.2 JVM 核心参数逐个拆解：每个参数背后的逻辑

JVM 参数非常多，但真正常用的核心参数就那一批，关键在于理解每个参数的适用场景和背后的权衡。我整理了一份参数清单，都是这次调优实际用到的，每个参数我都会附上调整理由和注意事项。

bash复制# 基础堆内存设置（服务器是 8G 内存）
-Xms4g
-Xmx4g
-Xmn2g
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=512m

# 垃圾收集器选择
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
-XX:G1HeapRegionSize=16m

# 吞吐与日志
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:/data/logs/gc-%t.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/

-Xms 和 -Xmx 是最基础的两个参数，分别设置堆内存的初始值和最大值。我的习惯是直接把它们设置为相同值，比如 4g，这样做的好处是避免 JVM 在运行过程中动态扩容和缩容，减少性能波动。服务器内存 8G，堆分配 4G 是合理的，剩下的留给 JVM 的元空间、线程栈、直接内存和操作系统本身。

-Xmn 设置新生代大小，这里是 2G。新生代的大小对 GC 频率影响很大——新生代越大，Minor GC 发生得越少，但会导致老年代变小，增加 Full GC 的风险；新生代太小，Minor GC 太频繁，对象晋升老年代的概率也会增加。对于订单导出这种大批量创建对象的场景，新生代 2G 是一个比较均衡的值。GC 日志里 Minor GC 的频率从原来的每几秒一次降低到了每 30 秒左右一次，效果非常直观。

-XX:+UseG1GC 是切换垃圾收集器。G1 和传统的 CMS、Parallel 相比，核心优势是把堆划分为多个大小相等的 Region，然后跟踪每个 Region 里的垃圾堆积情况，优先回收垃圾最多的 Region，配合最大停顿时间参数 -XX:MaxGCPauseMillis=200，可以让 Full GC 的发生概率大幅降低。-XX:InitiatingHeapOccupancyPercent=45 指的是当堆内存使用率达到 45% 时，G1 就开始启动并发标记周期，提前准备回收空间，而不是等堆快满了再着急 Full GC。-XX:G1HeapRegionSize=16m 则是把每个 Region 设置为 16MB，对于订单对象这种小对象为主的场景，这个尺寸能减少跨 Region 引用，提升回收效率。

2.3 GC 日志分析：用数据判断调优效果

调参不能靠猜，一定得用数据说话。JVM 提供了完整的 GC 日志输出能力，开启之后会在日志里记录每一次 GC 的类型、耗时、回收前后堆内存的变化。当时我在压测环境跑了一次 5 万条订单的导出任务，抓到的 GC 日志长这样：

bash复制[2024-03-15T10:23:45.123+0800] GC pause (G1 Evacuation Pause) (young) 1024M->512M(4096M), 0.023s
[2024-03-15T10:23:46.789+0800] GC pause (G1 Evacuation Pause) (young) 1536M->768M(4096M), 0.018s
[2024-03-15T10:25:12.456+0800] GC pause (G1 Humongous Allocation) (young) 2048M->1200M(4096M), 0.045s

注意第二行日志里的 Humongous Allocation，这是 G1 特有的一个概念，表示大对象分配。G1 规定，如果一个对象的大小超过 Region 的一半，比如 Region 是 16M，对象超过 8M，就会直接进入"大对象区域"（Humongous Object）。这些大对象如果长期存活，会把老年代的空间占得很碎，导致空间浪费。

当时我立刻反应过来，订单对象本身不大，问题大概率出在存储订单明细的 List 或者 POI 的 Excel 工作簿对象上。压测日志里频繁出现 Humongous Allocation，进一步验证了我之前的判断——一次性加载 5 万条数据的方案行不通。这就是 JVM 调优的价值所在：它能帮你逆向定位到代码层面的问题，而不是让你盲目加内存。

2.4 JVM 调优的几个关键注意事项

第一，慎改参数，每次只改一个。很多工程师喜欢一次性改一堆参数，出问题了都不知道是哪个参数引起的。我的习惯是每次只调整一个参数，跑一轮压测，对比 GC 日志，确认效果后再改下一个。改动前先记录基线数据，没有基线就谈不上优化。

第二，注意堆内存和系统内存的比例。服务器是 8G 内存，如果把堆设置成 6G，再加上 Metaspace、线程栈、JVM 自身开销和操作系统缓冲，物理内存很容易被打满，引发操作系统层面的 swap。一旦发生 swap，JVM 的性能会断崖式下跌。经验值是对 CPU 密集型服务，堆内存控制在物理内存的 50%-60% 比较安全。

第三，-XX:+HeapDumpOnOutOfMemoryError 这个参数在生产环境必须开启。有了它，当 JVM 发生 OOM 时，会自动把堆转储文件保存到指定路径，这能帮你在事后分析到底是谁占满了内存。线上不能现装 MAT 去连生产环境，但配上这个参数，OOM 数据就能自动保留下来了。

第四，也是最重要的一点，JVM 调优解决不了所有性能问题。如果 SQL 慢查询还在，JVM 调优只能让系统慢得稳定一些，不会让系统变快。这也是为什么完成 JVM 侧优化后，我马上转战 MySQL 慢查询，两件事必须一起做。

3. MySQL 慢查询优化完整流程

3.1 开启慢查询日志：找出罪魁祸首 SQL

JVM 侧已经基本稳定，接下来解决 MySQL 的慢查询问题。第一步不是猜哪条 SQL 慢，而是让数据库自己说出来。MySQL 的慢查询日志就是干这个用的。

我的习惯是分两步走：第一步，临时开启慢查询日志，在线确认慢 SQL 的执行情况；第二步，确认之后再写进配置文件，让它在长期运行中持续记录。临时开启的命令长这样：

sql复制-- 查看当前慢查询设置
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

-- 开启慢查询日志（临时生效）
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/data/mysql/logs/slow.log';

long_query_time = 1 意味着执行时间超过 1 秒的 SQL 都会被记录。有些 DBA 喜欢把阈值设成 10 秒，但我倾向于 1 秒——宁可慢查询日志多记一些，多花一点磁盘空间，也不要漏掉那些平时能跑但高峰期变慢的 SQL。线上跑了几小时后，在日志里看到一条 SQL 频频上榜，执行时间稳定在 8-12 秒：

sql复制SELECT
    o.order_id,
    o.user_id,
    o.order_amount,
    u.user_name,
    u.user_phone,
    od.product_name,
    od.product_price,
    od.product_quantity
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
LEFT JOIN order_detail od ON o.order_id = od.order_id
WHERE o.create_time BETWEEN '2024-03-01 00:00:00' AND '2024-03-31 23:59:59'
  AND o.order_status = 1
ORDER BY o.create_time DESC
LIMIT 50000;

一眼看过去，这 SQL 结构还挺清晰，但在数据量超过千万级的订单表上，这种多表 JOIN + 范围查询 + 排序 + 大偏移量 LIMIT 的组合，几乎就是慢查询的法宝。先用 3.2 小节的 EXPLAIN 分析确认一下。

3.2 EXPLAIN 执行计划：读懂 MySQL 的执行意图

EXPLAIN 是 MySQL 提供的一个 SQL 分析工具，它不会真正执行 SQL，但会告诉你 MySQL 打算怎么执行这条 SQL。这就像你让外卖骑手提前报一下走哪条路线，是走高速还是穿小路，每段路要花多久。我执行了 EXPLAIN 之后的结果如下：

sql复制EXPLAIN SELECT ... -- 同上完整 SQL

看到 type 列的值了吗？orders 表是 ALL，全表扫描，rows 显示 986 万，这是最致命的问题。谁做全表扫描，谁就是性能瓶颈。这里透露的信息很明确：order_status 和 create_time 这两个条件没有命中任何索引，MySQL 只能把整张订单表的数据捞出来，一条一条比对，然后还要对结果集做排序，所以 Extra 里也出现了 Using filesort——文件排序，把数据放到临时文件里排好序再返回，这在大数据量下极其耗时。

再往下看，users 表的 type 是 eq_ref，说明关联查询走了 PRIMARY 主键索引，效率很高；order_detail 表走的是 ref，用到了 order_id 索引，性能尚可。所以问题非常集中：orders 表本身没有可用的索引。如果只是加一个普通索引，能解决一部分问题，但要从根本上优化，还得看下面这几步。

3.3 索引设计实战：覆盖索引与延迟关联

第一反应是给 orders 表加索引，但加什么索引有讲究。如果只加单个字段索引，比如 create_time 索引，MySQL 在执行的时候会去索引里找到符合条件的行，再回表读取整行数据，拿到 order_status 和 user_id 继续判断，回表次数多了性能也会打折扣。更优的做法是使用复合索引（联合索引），把查询条件里最常用的列作为一个整体建索引。

结合这条 SQL 的 WHERE 条件和 ORDER BY，我建议用这样的复合索引：

sql复制ALTER TABLE orders ADD INDEX idx_create_time_status (create_time, order_status);

create_time 放在最左边，因为它是一个范围查询字段；order_status 跟在后面。MySQL 的复合索引遵循"最左前缀"原则，在查询条件里同时出现 create_time 和 order_status 时，这个索引能被充分利用。执行计划从 ALL 全表扫描变成了 range 范围扫描，rows 从 986 万降到了约 10 万，SQL 首次耗时从 8 秒降到了 2 秒左右。

优化到这里还没完，ORDER BY o.create_time DESC 中的排序问题虽然因为索引的有序性被部分解决了，但这条 SQL 还有一个大隐患——LIMIT 50000。MySQL 的 LIMIT 不是先找到 5 万条就够了，它的语义是"跳过前 50000 条，再返回接下来的数据"，也就是说它要把前 5 万条都查出来扔掉。假如用户点的是第 100 页，那 MySQL 要扫描 50 万行，性能依然难看。

于是我把 SQL 改写成了延迟关联（延迟 join）的写法：

sql复制SELECT
    o.order_id,
    o.user_id,
    o.order_amount,
    u.user_name,
    u.user_phone,
    od.product_name,
    od.product_price,
    od.product_quantity
FROM (
    SELECT order_id
    FROM orders
    WHERE create_time BETWEEN '2024-03-01 00:00:00' AND '2024-03-31 23:59:59'
      AND order_status = 1
    ORDER BY create_time DESC
    LIMIT 50000
) tmp
JOIN orders o ON tmp.order_id = o.order_id
LEFT JOIN users u ON o.user_id = u.id
LEFT JOIN order_detail od ON o.order_id = od.order_id
ORDER BY o.create_time DESC;

核心思路是：先用子查询在 orders 表上做窄表查询，只返回主键 order_id，这一步可以利用上我们刚建的复合索引；然后再用主键去关联回原表和其他表，获取完整数据。MySQL 在处理这种"先拿主键、再回表取数"的模式时，可以使用覆盖索引，需要在索引里就能找到 order_id，避免全表大扫描。优化后这条 SQL 的耗时降到了 300 毫秒以内，效果天差地别。

3.4 SQL 改写与分页策略：Limit 深分页的坑

继续深挖这条 SQL 可以发现一个 bug 级别的隐患——LIMIT 50000 这种写法的深分页问题。很多开发对 LIMIT 的理解有误，以为 LIMIT 50000 就是取 5 万条数据，实际上它取的是前 5 万条之后的数据，如果用户翻页到第 1000 页，MySQL 会先扫描 40 多万行，然后全部丢弃，只留最后一页的数据，这种开销是毁灭性的。

延迟关联能优化一部分，但更好的方案是用"增加一个游标条件"的方式来改写分页，比如用户上一次看到的最后一条记录的 create_time 或 id，下一次查询时直接 WHERE create_time < 上一次的最大值，这样无论翻到多深的页，SQL 都能通过索引快速定位到起点，不需要跳过大量数据。

sql复制-- 前一次请求最后一条记录的 create_time 和 order_id
WHERO o.create_time < '2024-03-28 12:30:00'
   OR (o.create_time = '2024-03-28 12:30:00' AND o.order_id < 123456)
ORDER BY o.create_time DESC, o.order_id DESC
LIMIT 20;

上面的 SQL 把"下一页"的条件由 OFFSET 改成了"定位到指定位置之后"，这种方案在百万级数据下也能稳定保持在毫秒级。这也是我在文首提到"先止损再优化"的另一个例子——如果业务方确实需要导出大量数据，更深层的方案应该是异步导出，把导出任务丢到消息队列里，由专门的线程池分批处理、写入 Excel 后再通知用户下载，而不是让用户在同一时刻等待一个同步接口完成全部工作。

4. 联合调优案例：批量导出场景的 JVM 与 MySQL 协同优化

4.1 问题现象：两边都很慢，但根因互相纠缠

前面把 JVM 和 MySQL 分开讲完了，但真实线上问题的精彩之处在于，根因往往是互相纠缠的。回到那个订单导出功能，如果只盯着 JVM 侧看，你会困惑为什么堆调大了 GC 还是频繁；只盯着 MySQL 侧看，你会发现 SQL 已经优化到 300 毫秒，但应用层还是慢。直到把两份监控数据放在一起对照，问题的完整画像才浮现出来。

现象是这样的：导出请求进来后，应用层先执行慢 SQL，在优化前要等 8 秒才能拿到 5 万条数据；此时这 5 万条订单数据全部进入 JVM 堆内存，堆里同时还有其他的业务对象，老年代迅速膨胀到 80% 以上，触发 Full GC；Full GC 影响的是整个 JVM 里所有线程，不管是导出请求还是普通查询请求，全部被 STW（Stop The World）卡住；数据库连接池的连接被慢请求长时间占用，其他请求拿不到连接，只能排队等待，应用的整体响应时间雪上加霜。

这种问题，拆开看 JVM 和 MySQL 好像都找到了问题，但如果不理解它们之间的相互影响，就会陷入修好一个又是一个的死循环。所以调优不能只看单点指标，要有全链路视角。

4.2 SQL 批量改写与 JVM 内存配额如何配合

解决思路是限制每次进入 JVM 的数据量，同时提升数据库端的数据输出效率。具体做了两件核心改造：

第一，SQL 侧把一次性查询 5 万条改成游标分批次查询，每批 2000 条。这个改动不仅减少了 SQL 的扫描范围，更重要的是把 JVM 堆里同时存活的对象数量控制在了可控范围内。2000 条订单数据占用的内存大约只有几 MB，老年代根本不会被打满。

第二，配合 JVM 侧的参数调整。把新生代的占比适当调大，给批次查询创建的临时对象更多缓冲空间；同时开启 G1 收集器的大对象优化。改造后 GC 日志里的 Humongous Allocation 明显减少，Full GC 从原来每小时 10 次左右降到了每天不到 1 次。

这里也提醒一下：分批查询不能生硬地使用 LIMIT offset, size，因为 offset 大了照样慢。正确做法是用 id 范围和 create_time 范围作为分批条件，比如每次查询 create_time >= 上次最大值 AND create_time < 上次最大值 + 1 小时，这样每次查询都命中索引，不受 total 数据量影响。分批的粒度以及批与批之间的间隔，需要根据业务容忍度调整，通常我会控制在单批查询耗时 100ms 以内。

4.3 从调优到预防：监控、告警与容量评估

优化完成之后，最怕的是过一段时间问题复发。预防的核心措施就是监控和告警。JVM 侧，用 Grafana + Prometheus 的 jmx_exporter 采集堆内存、GC 耗时、GC 频率、线程数等关键指标，配置告警规则：Full GC 次数超过 1 次/5 分钟就告警，堆内存使用率超过 85% 持续 5 分钟就告警。MySQL 侧，除了慢查询日志，还可以用 Performance Schema 和 sys 库来统计 TOP SQL，并配置主从延迟、连接数、QPS 的告警。

容量评估也不能省。根据这次压测的数据，每 2000 条订单结果集大约占用 3MB 内存，那么 4G 堆内存的理论并发上限大约是 1300 个左右的任务同时处理。但这是理想值，实际还要算上其他业务占用，所以我建议把最大并发控制在 200 以内，超过就直接拒绝或排队。这里的数字不是拍脑袋拍出来的，每一步都有推理依据，这就是调优工作和"碰运气"的本质区别。

另一件值得做的事，是建立定期压测机制。每季度对核心接口做一次压测，保存基线数据，对比本季度的性能指标是否有回退。很多性能问题不是突然发生的，而是慢慢劣化的——这周慢 1 毫秒，下周慢 1 毫秒，累积几个月没人察觉，等到大促时集中爆发，再排查就手忙脚乱了。定期压测能让你提前发现趋势异常，把问题消灭在早期。

5. 常见问题与排查技巧实录

5.1 JVM 调优高频踩坑：参数无效、内存溢出、OS 线程墙

JVM 调优实战中，有几类问题出现的频率非常高，几乎每个团队都会遇到。

第一类：改完参数没生效。这个问题的根源 90% 是修改没重启，或者启动脚本里用的是绝对路径而不是环境变量，JVM 实际读取的是脚本里 old 参数而不是你改的那个。排查这类问题很简单，启动进程后先执行 jinfo -flags <pid> 查看当前所有生效的 JVM 参数。注意，jinfo 只能查看部分参数，有些参数需要加 -XX:+PrintFlagsFinal 才能看到完整列表，比如直接运行 java -XX:+PrintFlagsFinal -version | grep MaxHeapSize 查看当前 JVM 认为的最大堆是多少。

第二类：OOM 了但不知道是谁干的。这种时候，-XX:+HeapDumpOnOutOfMemoryError 是你的救命稻草。OOM 发生时自动 dump 出堆文件，用 MAT 的 Leak Suspects 功能分析，基本一眼能定位到哪个类占了最多内存。MAT 还能查到线程栈与对象的引用链，帮我们找到谁创建的这些对象。只要这个参数开了，OOM 排查基本都不会太困难。

第三类：JVM 线程数暴涨导致操作系统崩溃。这个问题经常发生在大量线程被阻塞的时候。Java 的线程和 OS 线程是一一对应的，每一个 Java 线程都会消耗一块原生内存作为线程栈（默认 1MB），所以线程数过多会直接压垮 OS 内存。排查手段是 jstack <pid> > thread_dump.txt 抓线程栈，统计 BLOCKED、WAITING 状态的线程数量，看看堆积的线程都在等什么锁。通常这种问题的根源还是 SQL 慢查询把连接池占满，线程拿不到连接，全部阻塞堆积，回头优化 SQL 才是治本。

5.2 慢 SQL 优化高频踩坑：索引失效、隐式转换、回表过多

MySQL 慢查询优化的踩坑点比 JVM 更隐蔽，很多 SQL 你以为加了索引就万事大吉，结果 EXPLAIN 一执行，发现压根没走索引。这里列出我遇到最多的三种情况。

第一种：索引失效，最常见的就是对索引列做了函数操作或者隐式类型转换。比如 WHERE DATE(create_time) = '2024-03-15'，这个写法会让 create_time 索引完全失效，因为 MySQL 无法直接对函数计算结果做索引查找，只能全表扫描。正确写法是 WHERE create_time >= '2024-03-15 00:00:00' AND create_time < '2024-03-16 00:00:00'。另外，如果字段类型是字符串，查询参数是数字，MySQL 会做隐式转换，同样会让索引失效。比如 WHERE user_id = 123，但 user_id 是 varchar 类型，就需要写成 WHERE user_id = '123'。

第二种：回表过多。即使 SQL 走了索引，如果索引里包含的列不够覆盖查询需要的所有列，MySQL 每找到一条索引记录，都要回到主键索引去查完整行数据，这就是回表。一张 1000 万行的表，回表 10 万次，性能肯定好不了。解决办法是设计覆盖索引，把查询需要的列都放进索引里，让索引"覆盖"查询需求。比如我们之前建的复合索引 (create_time, order_status)，如果查询只需要这两个字段加主键，就没有回表了，查询速度会快上一个数量级。

第三种：OR 条件导致优化器放弃索引。比如 WHERE create_time > '2024-03-01' OR order_status = 1，MySQL 的优化器可能会认为走索引还不如全表扫描，因为 OR 两边可能需要不同的索引。处理方式是拆分成两个查询用 UNION ALL 合并，或者改造 SQL 逻辑减少 OR 的使用。还有一种比较隐蔽的情况是字符集不一致导致索引失效。JOIN 的两张表，一张用 utf8mb4，一张用 utf8，关联字段的类型和排序规则不一致，MySQL 需要转换后才能比较，索引也会失效。排查时可以用 SHOW CREATE TABLE 看一下表结构，把所有表的字符集统一成 utf8mb4 是最保险的选择。

5.3 长时间运行后的再次劣化：统计信息过旧与索引碎片

有些问题不会在你调优的当下发生，而是在运行几周甚至几个月后才冒出来。SQL 压测时明明 100 毫秒，线上跑了一个月变成了 2 秒。最常见的原因是 MySQL 的统计信息过旧，导致优化器选错了执行计划。InnoDB 引擎的优化器会根据索引的基数（Cardinality）来决定是否使用索引、使用哪个索引，如果统计信息不准确，它可能做出错误决策。解决方法是定期执行 ANALYZE TABLE orders，让优化器重新收集统计信息。生产环境可以设置一个定时任务，在业务低峰期自动执行。

索引碎片是另一个隐形杀手。频繁的插入、更新、删除操作会让索引页产生碎片，索引的 B+ 树变"松散"，磁盘 IO 相应增加。用 OPTIMIZE TABLE orders 可以重建表并整理索引碎片。这里要注意，OPTIMIZE TABLE 期间会锁表，对在线业务影响很大，必须安排在维护窗口执行，或者用在线 DDL 工具来减少阻塞。

5.4 调优工具速查表：从入门到进阶

上面讲了不少命令，最后整理一份工具速查表，方便你实际操作时快速定位。工具不在多，关键是用对场景。

这个表格是给新手画的一个行动地图，拿到问题先按表格匹配工具，省得东一榔头西一棒子。等用熟了这些工具，你对线上问题的敏感度自然就上来了。

6. 调优之外：一些掏心窝的体会

JVM 调优和 MySQL 慢查询优化，说到底都不是一锤子买卖。我记得刚入行那会儿，以为调优就是把参数改大点，后来线上出事故才明白，光靠改参数是走不远的。真正的调优是要理解业务的数据特征和访问模式——订单表为什么慢，是因为数据量大还是查询条件设计不合理；导出功能为什么卡，是因为数据全塞内存还是 SQL 本身低效。离开了业务场景谈参数，就是在耍流氓。

再分享一个小技巧：每次调优前，先花 10 分钟把当前的性能基线记录下来，包括吞吐量、TP99 延迟、GC 耗时、慢 SQL 数量这些指标。调优后重新测量，对比基线数据，这样你的每一项改动都能量化收益。我见过不少开发调优完全凭感觉，改完觉得好像快了，但问他快了多少、哪个参数起了作用，却答不上来。没有基线的调优，就是没有航向的航行。

最后想说的是，如果这篇文章你只能记住一个点，我希望是"先测量，再优化，最后预防"。不管是 JVM 还是 MySQL，数据永远是决策的依据。下一次你再遇到接口慢、CPU 飙高、数据库连接被打满的时候，先别急着改代码，打开监控面板，把 GC 日志和慢查询日志翻出来看看，顺着数据找源头，问题的答案往往就藏在那几行日志里。