7.3 参数调优

7.3 参数调优

本节摘要：参数调优的正确顺序是先定位后动手、先 SQL 后参数、先资源后行为。本节把生产参数分成三级（必须自己算、按负载选、默认就好），给出调优决策链与效果验证法，帮你避开"调了一圈没变化"的无效劳动。

一条军规：没定位就动手的调优是赌博

性能工单的常见开场是"帮我调下参数"。如果不知道瓶颈在哪就调参，收益是随机的，风险是真实的——内存参数给大会颠簸，刷盘参数放松会伤可靠性。本节立的军规只有一条：任何参数变更前，先拿出定位证据（监控趋势、执行计划、等待事件分布），变更后拿出对比数据（同口径压测或业务指标前后对照）。参数调优是外科手术，不是保健按摩。

参数三级分类：把精力花在刀刃上

第一级，必须按机器自己算的。内存三件套（共享缓冲区、工作内存上限、日志缓冲）按 2.2 的账算：共享区覆盖热数据头部、私有区乘并发峰值不得溢出物理内存、日志缓冲匹配写入压力。这一级没有通用值，抄别人的等于穿别人的鞋。第二级，按负载形态选档的。日志刷盘与提交等待参数在"每笔提交都要等落盘"与"批量友好微秒级权衡"之间选档，交易库选严格档、分析库选宽松档；清理相关参数按膨胀压力调（第 3 章的治理清单）；检查点间隔在恢复时长与运行期 IO 平滑之间取舍（重负载批量库适当放宽）。第三级，默认就好的。大多数参数保持默认——文档默认值经过大量回归，除非有定位证据，不动。

-- 调参前先建立基线快照（示意流程）
SHOW shared_buffer_size;   -- 确认当前值
SHOW work_mem_limit;       -- 私有区相关
-- 变更落地：分环境推进
-- 测试环境改配置文件并重启验证，生产环境热生效参数走在线修改并观察
-- 效果验证：同一条基准 SQL 前后各跑十次取中位数对比
​

调优决策链：顺序就是效率

这条链的顺序有讲究。SQL 优化永远排在参数之前，因为错误的执行计划能让任何参数都白搭——计划从全表扫描改索引扫描，收益是十倍量级；参数调优的收益通常是百分之几十。资源参数排在行为参数之前，因为资源不足时行为参数是在错误的前提下做微调。每一步都要走"变更—验证—固化"闭环，固化进基线表时写明理由与验证数据——这是 7.1 交割文档的动态延续。

效果验证法：同口径对照才作数

参数效果验证的三个坑。坑一，混合口径：改参数前后用了不同的数据量或并发，对比无效。正确姿势是固定一份基准负载（固定的几条代表性 SQL 加固定并发脚本），改前跑十次取中位数、改后同法再跑。坑二，只看均值不看长尾：参数调优常常改善均值却恶化长尾（或反之），耗时分布的两个分位都要看。坑三，忽略连带影响：私有区内存调大让单查询变快，但并发上来后内存溢出颠簸，整体反而更差——验证负载要覆盖峰值并发场景。一个正面案例：某报表库排序溢盘频繁，把排序内存按并发峰值重算后调大一档，基准报表从四秒降到一秒六，长尾分位同步改善，且峰值并发压测未出现内存颠簸——三步验证走全，这个变更才固化进基线。

常见参数误区清单

误区一，照抄网上"性能优化十参数"：别人的机器、负载、版本都与你不同，抄来的配置多数无效、个别有害。误区二，把参数当架构：单机扛不住的写入量，调参救不了，该上形态升级就升级（回看 2.3）。误区三，热生效滥用：支持在线修改的参数也要走变更窗口，改完就跑的"隐身变更"是排障地狱的起点。误区四，忘记回滚点：每个参数变更前记录原值，验证失败立即回退——没有回滚点的变更不是变更，是事故预定。

一级参数的三笔算式

内存参数的"自己算"要落到算式上，给出三笔常用算式的模板。算式一，共享缓冲区：取热数据工作集估算值与物理内存的固定比例两者中的较小者——工作集从监控与业务方联合估算（活跃账户数乘单账户数据尺寸是常用近似），比例上限五到六成。算式二，单操作内存上限：典型报表的排序数据量除以可接受的溢盘阈值，再留五成余量——排序数据量可以从 4.3 的实际执行账单里直接读。算式三，并发总内存校验：单操作上限乘并发执行算子的会话峰值，加共享区总量，不得越过物理内存减预留。三笔算式都需要业务方的两个输入：活跃数据规模与报表并发峰值——所以参数评审会必须请业务方到场，闭门造车的算式输入全是猜。

行为参数的两个案例裁决

行为参数按负载选档，用两个裁决示例演示推理过程。裁决一，交易库的提交等待：业务方口径是"任何已确认成功的数据绝不能丢"，裁决为严格档——每次提交等备机确认；代价是提交延迟上升约一毫秒，业务方点头接受。裁决二，报表库的检查点间隔：批量导入期间检查点频繁触发导致 IO 尖峰，裁决为放宽档——恢复时长从两分钟变成六分钟，业务方确认恢复时长可容忍。两个裁决的共性：参数档位的选择权在业务方，工程师的职责是把每个档位的代价翻译成业务语言。反过来，工程师单方面拍板的"最优参数"，往往在故障复盘时变成争议点——把裁决权还给业务，把翻译责任留给自己。

现场问答三则

问答一："参数改完立刻生效了吗？"——分两类：支持热加载的参数改完即生效但只影响新会话，存量会话要重连才能享受；需要重启的参数变更必须排窗口，别在故障处理时顺手改了重启型参数。问答二："网上说这个参数调大有奇效，要不要试？"——先问三个问题：他的硬件配置与你一样吗、他的负载形态与你一样吗、他有没有给出对照数据，三个问题有两个答不上来，就把这个建议放回收藏夹。问答三："调优有没有终点？"——有，性能满足业务目标且余量合理就是终点；持续调优的边际收益递减，把精力转投到监控与容量规划上更有价值。三则问答分别对应变更语义、经验鉴别、止损边界，都是调优现场的实战共识。

调优工作的边界清单

调优开始前，先明确哪些事不属于参数调优的射程，避免用错力。射程之外的四件事：数据分布与分片设计不合理——这是设计期决策，参数救不了倾斜与跨节点放大的天生缺陷；应用架构的串行调用——数据库单次再快，应用里排队五次的总时延还得从应用侧解；硬件资源的天花板——盘的带宽与核的算力是物理边界，参数只是逼近边界而非突破边界；版本自身的缺陷——遇到内核行为的异常，走社区反馈与补丁路径，别指望参数绕过。调优工程师的价值排序也由此清晰：先判断问题在不在射程内，再决定是否动手——把非参数问题指给正确的负责人，与把参数问题漂亮地解决，是同一种专业能力。

参数评审会清单

参数变更落地前过一遍这份六项清单，缺一项就回炉：一，定位证据——变更解决的那个瓶颈有监控或账单数据佐证；二，算式依据——新值来自参数基线表的算式而非拍脑袋；三，影响面评估——这个参数波及哪些负载与哪些用户，最坏情况是什么；四，回滚方案——原值已记录，回退命令写在变更单上；五，验证方案——用什么口径验证效果，谁来看结果；六，固化计划——验证通过后何时更新基线表与运维手册。清单过一遍约十分钟，但它把参数变更从"手感活"变成"流程活"。评审会上最常被卡住的是第三项与第六项——影响面没人说清、固化没人负责，这两个坑提前填好，变更通过率会高很多。

本节要点回顾

• 先定位后动手：没有证据的调参是赌博，军规只有这一条；
• 三级分类：内存按机器算、行为按负载选档、其余保持默认；
• 决策链顺序：SQL 先于参数、资源先于行为、每步走变更验证固化闭环；
• 验证三防坑：同口径、看长尾、测峰值并发；
• 永远留回滚点：变更前记录原值，失败立即回退。

参数的收益终有上限，结构性优化要看案例——下一节用三个完整实战把全章方法论跑一遍。