做后端时间长了你会发现“参数体系与调优”这几个字几乎能概括研发和运维之间一半的争论。前几天一个朋友让我看一个 MySQL 实例我说先查 innodb_buffer_pool_size他说默认再问 JVM 的 -Xmx他也说默认。服务确实没崩但一到月底对账批量任务就跑不动CPU 上去了TPS 掉下来业务方天天催。我把整个服务从上到下扒了一遍发现真正的问题不是某个参数“太小”而是整套参数跟业务模型完全不匹配。这就是我写这篇文章想说的核心参数体系不是一堆散装的配置项它是一整套相互制约、需要按场景联调的资源分配策略。这篇文章会从 MySQL 性能调优、JVM 调优、批量调优三个角度讲清楚一个从业者拿到一个“有点慢”的系统时应该先看什么、怎么算、怎么改、怎么回滚。适合刚接手线上服务的新人也适合那些已经改了不少参数但心里没底的后端和运维同学。1. 参数体系到底在调什么1.1 别把“调参”当“调优”我先泼一盆冷水大部分线上服务跑在默认参数下一点问题都没有。MySQL 的默认配置能扛住绝大多数中小型业务JVM 的默认堆也能支撑日常流量。真正需要调参的场景通常是业务特征已经偏离了默认设计。比如数据量涨了十倍内存只有 16G热点却集中在最近几天的数据上或者批量任务一次要处理几百万行事务大小直接把 redo log 打爆又或者服务偶发 Full GC但堆内存明明还有一半空闲。把调参当调优最常见的动作就是“网上搜到一篇文章照着把几个参数拉大”。我见过有人把 MySQL 的 sort_buffer_size 调到 64M理由是“排序快了”结果这个参数是每个连接独享的连接数一多内存直接耗尽服务 OOM。还见过有人把 JVM 的 -Xmx 从 4G 加到 8GFull GC 不但没减少反而更频繁因为堆大了GC 扫描时间更长对象晋升路径也变了。所以第一步不是改参数是先搞清楚这套参数在系统里负责什么改了之后会影响谁。1.2 先画清楚三层参数地图我习惯把参数体系拆成三层来看每一层调优的目标和手段完全不一样。第一层是数据层以 MySQL 为主。核心参数围绕内存缓存、连接管理、日志落盘、临时表这几个方向。这一层的调优本质是“用内存换磁盘 IO”因为数据库最大的瓶颈通常不是 CPU而是磁盘的随机读写。innodb_buffer_pool_size 这类参数决定了你有多大数据页能留在内存里直接影响查询命中率。第二层是应用运行时层以 JVM 为主。核心参数围绕堆内存、线程栈、垃圾回收器、元空间。这一层的调优本质是“控制停顿和吞吐的平衡”GC 停顿越少接口响应越稳定但可能牺牲一点吞吐量堆越大对象越不容易被回收但 Full GC 一旦发生停顿也越吓人。第三层是业务执行层尤其是批量任务。核心参数围绕批次大小、事务边界、并发数、重试策略。这一层的调优本质是“在数据库锁、网络 IO、应用内存三者之间找最小公约数”。很多批量任务慢不是 SQL 写得差是批次太大导致长事务长事务导致锁等待和 undo 膨胀再反过来拖慢 SQL。这三层不是独立的。我遇到过最有意思的案例是一个订单同步服务每天积压几十万条消息数据库 CPU 飙升。第一反应是慢查询结果慢日志里全是普通 insert。最后发现是批量任务的 batch_size 被从 1000 调到了 5000单批事务变大锁竞争指数级上升应用侧等待 DB 返回连接池被打满然后整个链路雪崩。你看应用层一个参数能把数据库层拖垮。所以调优必须站在“参数体系”的高度看问题而不是单点改一个配置就完事。2. MySQL 参数调优先把 buffer pool 和连接数搞清楚2.1 值得先动的核心参数MySQL 的参数有几百个但 90% 的场景你先要关注的其实是下面这几个。innodb_buffer_pool_size 是最重要的一个。它缓存数据页和索引页直接决定热数据在内存里能留多少。太小会频繁淘汰缓存页产生大量磁盘读太大留给操作系统和文件系统缓存的空间就不够还可能触发 swap。经验值是可用内存的 50% 到 70%但具体要看数据量和热点分布。max_connections 是第二容易被误调的。很多团队看到报错“Too many connections”直接把 max_connections 加到 2000。但实际上每个连接都要占用线程栈和内存连接数越多MySQL 内部调度压力越大。更关键的是你的应用连接池同时也就几十个连接把 MySQL 的连接上限调到 2000只是把问题往后拖真正该做的是看有没有连接泄漏。innodb_log_file_size 和 innodb_log_buffer_size 容易被忽略。redo log 是崩溃恢复用的日志太小事务提交频繁刷盘写性能上不去。尤其是批量导入数据时如果 log_file_size 只有默认的 48M你会发现“正常查询还行一写大量数据就卡”。sort_buffer_size、join_buffer_size、tmp_table_size 这三个要特别小心因为它们都是会话级参数按连接数累乘分配。sort_buffer_size 设成 8M两百个连接同时排序就是 1.6G 内存。除非你明确知道某个连接在做大排序否则别轻易往大了调。2.2 用真实业务场景算一次参数我来拆一个真实订单库的调整过程帮助你理解怎么“算”参数而不是“猜”参数。机器配置是 16G 内存、8 核 CPU数据总量约 80G其中订单主表 50G历史数据占绝大多数。业务特征是90% 的查询都在查最近 3 天的数据我让运营拉了一下统计这 3 天数据大概 4.2G 左右。也就是说理论上只要让最近热点数据和对应的索引都进内存查询命中率就能高得离谱。我的计算过程是这样的先确认只能分给 MySQL 的内存。机器上还跑着监控 agent、备份脚本和一些系统进程预留 2G 给操作系统和文件缓存比较安全所以 MySQL 最多能拿 14G 左右。按 70% 的上限来算是 9.8G但考虑到热点只有 4.2G我最终选了 8G。理由很简单buffer pool 不是越大越好还要留出空间给排序、临时表和连接缓冲。改完之后我在业务高峰期抓了一次指标SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_read_requests; SHOW GLOBAL STATUS LIKE Innodb_buffer_pool_reads;它们分别代表“从 buffer pool 读的总次数”和“从磁盘读的次数”。用公式 (read_requests - reads) / read_requests 算命中率调整前大概是 95% 左右调整后稳定在 99.6%。命中率每提升一个点对磁盘 IO 的减压都非常明显慢查询量直接砍掉三分之一。2.3 修改 MySQL 参数的正确姿势线上改参数我的流程非常固定否则容易把自己坑了。第一变更前先记录所有要改参数的现值用 SHOW VARIABLES 查出来存到一个文件里。第二一次只改一个参数改完观察 10 到 15 分钟看 CPU、IO、慢查询、活跃连接四个指标。第三优先用动态参数在线修改比如 innodb_buffer_pool_size 在 5.7 及以上可以直接 SET GLOBAL不用重启但 innodb_log_file_size 这类参数必须改配置文件重启生效你要把这部分变更放到低峰期。第四任何参数改完都要在配置文件里同步刷新确保重启后不丢配置。还有一个很容易踩的坑修改全局参数后已经存在的连接不会立即感知。比如你 SET GLOBAL max_connections 500但当前连接池里的老连接还是按旧值来限制的必须等它们重连。所以在线调参之后最好配合连接池的滚动重启或者干脆把动态参数和连接池参数一起看。注意改配置文件之前一定要先备份原始文件。MySQL 某些参数写错了重启会直接起不来没有备份就只能靠现场救急了。3. JVM 参数体系堆、GC、连接池三个入口3.1 堆参数不能上来就加内存JVM 的调优一半人栽在“堆越大越好”这个想法上。我承认把 -Xmx 调大确实是解决 OOM 最直接的手段但它只是把问题往后延并没有解决对象为什么增长得这么快。线上服务我更建议 -Xms 和 -Xmx 设成同一个值。很多人喜欢把 -Xms 设小一点等峰值时让 JVM 自己扩容听起来很省内存但扩容动作本身会触发堆结构调整造成一次额外的停顿。如果机器内存够用就让 JVM 启动即按最大堆来跑避免运行时抖动。堆内存到底留多少有一个很糙但实用的算法先观察业务高峰期堆占用率我一般看 GC 日志里老年代占用曲线。如果老年代在峰值期稳定在 60% 到 70% 以下说明堆大小是健康的如果经常冲到 85% 以上即使没有 Full GC也说明你离天花板太近一次流量抖动就可能出事。规律是先判断是“堆太小”还是“对象泄漏”再决定是否扩堆。判断方法很简单如果是泄漏堆会持续增长Full GC 也回收不干净GC 日志里每次 Full GC 后堆占用率还是居高不下如果是堆太小Full GC 后占用率会明显下降但下降后又会很快涨回去。这两种情况处理方式完全相反前者要查代码后者才需要加内存。3.2 GC 参数怎么选怎么调JDK 8 时代大家主要用 CMS但 CMS 在 Oracle 的支持周期已经结束新项目或者能升级的项目我建议直接上 G1。JDK 11 和 JDK 17 里 G1 已经是默认垃圾回收器了不用额外配置但 JDK 8 需要显式加 -XX:UseG1GC。G1 的核心参数其实不多-XX:MaxGCPauseMillis 默认是 200ms表示软目标不是硬性保证-XX:InitiatingHeapOccupancyPercent 默认 45表示老年代占用到 45% 时启动并发标记周期-XX:G1HeapRegionSize 默认会根据堆大小自动计算。很多人在 G1 上调了半天实际上这三个参数已经足够解决 80% 的问题了。我分享一个实际案例。一个广告报表服务业务方反馈每天下午 Full GC 频繁接口响应从几十毫秒飙到 2 秒。团队第一反应是堆不够把 -Xmx 从 4G 加到 8G结果情况更糟。我接手后先抓 GC 日志发现一个有意思的现象年轻代回收得非常干净但老年代占用率每轮都缓慢上涨而且元空间 Metaspace 的占用率也在涨。打开堆转储一看发现有一个静态 Map 在持续接收外部配置且从未清理每次更新配置都会增加一个新的键。这是典型的“元空间与堆双重泄漏”光扩堆没有用。处理方式是把漏对象的来源断掉然后给 JVM 加上 -XX:MaxMetaspaceSize512m 作为兜底再配合 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs这样下次再出问题至少能直接拿到堆转储文件分析。3.3 数据库连接池的 JVM 侧配合连接池参数严格说不属于 JVM 参数但调优时绝不能分开看。连接池大小不止是“开多少个连接”的问题它直接占用 JVM 堆内存和线程栈也直接影响数据库的最大连接数。HikariCP 官方给过一个推算公式核心数乘以 2 加 1也就是 8 核机器建议 17 个连接。这个数字看起来很小很多人不信但它背后的逻辑是这样的连接池大小不是越大越好而是刚好能把磁盘 IO 和 CPU 同时打满。连接数超过这个值额外的连接绝大部分时间都在等待徒增内存和数据库锁开销。如果业务里确实有慢查询或批量任务我会把连接池分成两到三个独立池子普通接口用一个池批量任务用另一个池避免批量任务把连接占满后拖垮在线接口。这个设计不是参数问题但它是让参数体系能正常工作的重要基础。4. 批量调优批次大小不是越大越好4.1 批量任务为什么慢三个放大效应批量任务性能差第一大原因是“单条 SQL 执行时间正常但批次数太大把问题放大了”。比如一次处理 100 万条数据每条 insert 要 2ms你以为总耗时就是 200 秒实际上完全不是。批处理过程中事务持有的行锁会挡住其他会话的读写undo log 会膨胀binlog 会变大主从复制也可能跟不上。这就是批量任务的三个放大效应锁放大、日志放大、内存放大。锁放大是最隐蔽的。一条 insert 只锁一行时没人注意。但在一个大事务里这个事务持有锁的时间被拉长任何并发操作都要等。我见过最夸张的案例批量任务每批 5 万条跑起来后整个订单表的查询全部排队接口作者 CC 数直接爆表。改小批次到 2000 条数据总量没变锁持有时间拆分并发立刻恢复。日志放大表现在 redo log、undo log 和 binlog 三处。事务越大日志缓冲越容易刷盘刷盘是同步 IO必然拖慢整体写入。批量任务每批的大小本质是在“日志刷盘的开销”和“提交次数”之间找一个平衡点。批次太大单次刷盘的数据太多批次太小提交次数太多每次提交的 fsync 延迟也不可忽视。4.2 一批 500 万行订单同步的调优过程我拿一个真实的订单同步任务当例子数据量 500 万行需要从老库搬到新库逻辑上不是简单迁移而是每行都要做清洗和补字段所以没法用 MySQL 原生的导表工具。第一版应用里写了一个 for 循环一条一条查出来清洗再一条一条 insert。跑了将近 6 个小时。这个方案最稳因为事务只有一条记录出错了重试也容易但速度完全不可接受瓶颈在应用层和数据库之间的网络往返上每行两次往返总共一千万次。第二版改成每 500 条一个事务使用 JDBC 的 addBatch 和 executeBatch清洗逻辑不变。总耗时直接降到 2 小时左右。因为网络往返从一千万次变成两万次事务提交变成两万次。注意这里不是盲目加大批次500 这个值是从重做日志缓冲大小和 binlog 缓冲综合考虑的5.7 的 innodb_log_buffer_size 默认是 16M500 条订单数据清洗后的行记录大概 1.2M留有充足余量。第三版再往下压发现单线程跑已经接近磁盘的写入上限CPU 还没有完全打满。于是按订单表的主键做范围分片分成 4 片4 个线程并发跑。4 个线程总耗时从 2 小时压到 45 分钟左右。为什么是 4 不是 8?因为后端库用的是普通 SSD实测并发写 4 个线程时 IO 已经接近峰值加到 8 个线程耗时反而因为锁竞争回到了 1 小时。数据不会骗人每一步都要测不要靠猜。4.3 批量调优的参数清单经过这个项目我梳理出一份批量任务的参数清单每次排查时按顺序过一遍。第一批是“批次相关参数”batch_size、事务提交频率、每条 SQL 的 timeout。批次大小的选择没有一个万能值但可以参考一个原则确保单个事务产生的 redo log 和 undo log不超过内存缓冲区的四分之一。第二批是“并发相关参数”线程数、分片策略、队列容量。线程数不能只看 CPU 核数还要结合数据库的 IO 能力和锁竞争情况。分片策略优先选主键范围分片避免索引失效。第三批是“容错相关参数”重试次数、重试退避策略、失败记录落库。批量任务跑了一个小时之后失败比批跑五分钟失败麻烦得多所以每批失败后要能定位到批次提供“断点续跑”的能力这也是广义参数体系的一部分。5. 常见问题与排查技巧实录5.1 调优前后对比的陷阱调优最容易出问题的地方不在改参数而在验证。很多人调完之后拿“今天和昨天比”来下结论这是不靠谱的。线上流量天然有波动昨天高峰期是 1 万 QPS今天是周末只有 6000你可不能把性能提升归结于调参。我自己做验证时会用以下方法。先确保对比周期内业务请求量型状接近最好挑同一个时间段比如都是工作日下午的两个小时。再同时看多个指标不只是 TPS、平均响应时间还包括 CPU、磁盘 IO、GC 停顿、慢查询数量。如果平均响应时间下降了但 CPU 和 IO 都没变化说明调优可能只是优化了某个边缘路径或者对比本身就是干扰。比较稳妥的方法是压测。压测不是生产环境但你可以用压测工具把接口打到接近生产峰值的压力然后对比改动前后的吞吐和延迟分布。生产环境的流量不会按照你的想法走压测能提供一个相对可控的对比环境。5.2 常用参数速查表我把这些年线上最常用的参数整理成了一份速查表方便你对照排查。MySQL 核心参数速查参数默认值5.7/8.0常见问题参考调整方向innodb_buffer_pool_size128M磁盘命中率低、慢查询多可用内存的 50%-70%结合热点数据量max_connections151连接数告警配合应用连接池避免无脑调大innodb_log_file_size48M批量写入卡顿结合 redo log 每小时生成量调整sort_buffer_size256K排序临时表过多谨慎会话级参数按连接数分配tmp_table_size16M大临时表落盘结合业务中临时表大小小幅上调JVM 核心参数速查参数使用场景常见坑建议-Xms / -Xmx堆大小只调大不调小忽略内存余量生产环境建议设为相同值-XX:MaxMetaspaceSize避免元空间无限增长不设上限导致 Native 内存泄漏设一个兜底阈值-XX:MaxGCPauseMillisG1 GC 停顿目标设太小导致 GC 频繁200ms 起步观察调整-XX:HeapDumpOnOutOfMemoryErrorOOM 排查忘记配置OOM 后无从下手必须配合 HeapDumpPath批量任务参数速查参数影响负优化方式推荐姿态batch_size事务大小、锁竞争、日志量一次几万条从 500 起测观察锁和日志并发线程数数据库 IO 压力8 核就开 32 线程从 4 起测观察 CPU 和锁等待提交频率fsync 次数、数据一致窗口每条一提交分批提交设置合理间隔5.3 几个我踩过的坑性能调优这条路我踩过的坑比收获的经验多得多。我只列三个印象最深的给大家打个预防针。第一个坑在没做基线记录的情况下直接调参。当时年轻随手把某个服务的 MySQL 参数改了好几个改完发现确实快了但不知道是哪个参数起的作用更不知道哪个参数其实拖了后腿。后来我养成了习惯任何一个参数变更前先导出当前参数快照和性能基线再动手。第二个坑忘了连接池的“存量连接”问题。有一次我 SET GLOBAL max_connections 1000结果线上还是有连接数告警。查了半天发现应用连接池里的旧连接仍然按旧参数活动必须滚动重启。从那以后在线调参我都会同步通知业务方让应用连接池做一次平滑重连。第三个坑把 GC 日志和监控割裂开看。以前只看 GC 日志频率下降了就觉得 GC 优化成功结果接口延迟一点没好。后来把 GC 日志、接口耗时、CPU 使用率画在一张图上看才发现某一轮 GC 时间虽然变短了但发生频率升高整体停顿时间反而变长了。调优这件事最能误导人的就是“单项指标变好”。我个人在实际操作中最深的体会是参数体系调优本质上是在给系统“校对边界”。先摸清业务模型和数据特征再改参数改一个看一眼留足回滚空间最后一定要用监控和压测说话不要用“感觉”说话。这套流程看起来笨但长远来看却是最稳妥、最省事的做法。